On Jan 30, 2006, at 5:35 PM, Bruce D'Arcus wrote:
CitationStyle
==
new (load external CSL file and create object)
OK, here's a start; sorry, just easier for me to think in Ruby. Feel
free to jump in and translate to Python if you want. I'm posting this
step by step just to make sur
On 1/30/06, Ed Summers <[EMAIL PROTECTED]> wrote:
> You typically want to test how a user will want to use your library.
> You don't want to write tests for internal stuff. If there are a
> sequence of interpendent events that need to be tested I tend to
> bundle them in an individual test method.
You typically want to test how a user will want to use your library.
You don't want to write tests for internal stuff. If there are a
sequence of interpendent events that need to be tested I tend to
bundle them in an individual test method.
Testing does take time. When you first start writing them
On Jan 30, 2006, at 12:08 PM, Ed Summers wrote:
Yep, write tests for the code that doesn't exist and run them and
watch them fail. Then start filling in the code until you can get
tests to start passing. When all the tests pass you're done!
Yes, but how find-grained do you get? Take a method
On 1/30/06, Bruce D'Arcus <[EMAIL PROTECTED]> wrote:
> I still need to wrap my head around this (particularly exactly what
> kinds of methods to create tests for), but I guess the idea is to
> create a file full of this sort of stuff?
Yep, write tests for the code that doesn't exist and run them a
OK, here's a simple unit test that passes:
#! /usr/bin/env ruby
require 'citeproc'
require 'test/unit'
class TestReference < Test::Unit::TestCase
include CiteProc
def data
[
{
:creator => ["Doe, Jane", "Jane Doe"],
:title => "Some title",
:year => "1999",
On Jan 29, 2006, at 11:21 PM, Edward Summers wrote:
I'm psyched you agree pt :-) Defining a set of tests that illustrate
how to use the API might be a good way for us to visualize how the
library could be used, and for us to measure our success as the
library gets fleshed out.
Oh, OK.
[1]
On Jan 30, 2006, at 8:31 AM, Edward Summers wrote:
Heh, doesn't look like you need much help from me for programming :-)
Well, I did have help with some of the hard stuff. I had no clue how to
do the grouping and sorting stuff for the author-date class!
Still, I think it bears repeating th
On Jan 29, 2006, at 11:03 PM, Bruce D'Arcus wrote:
More tomorrow; gotta go to bed.
Heh, doesn't look like you need much help from me for programming :-)
Still, I think it bears repeating that looking at your library from
the outside first might help in this design process.
//Ed
On Jan 29, 2006, at 10:32 PM, Edward Summers wrote:
Bruce, I'm interested in helping out with this. I'm pretty familiar
with both ruby and python but I don't have a good grasp on what
exactly you want to do. Assuming the library existed could you flesh
out how it would be used programatically
On Jan 29, 2006, at 9:52 PM, pt wrote:
I agree that test-driven development will help a lot here.
One starting point would be tests that show you can load data into
some object from the RDF serialization suggested by Bruce then re-
serialize it back out. Trivial to implement at first, but ne
I agree that test-driven development will help a lot here.One starting point would beĀ tests that show you can load data into some object from the RDF serialization suggested by Bruce then re-serialize it back out. Trivial to implement at first, but needs to be there as more code gets built.
Bruce,
On Jan 28, 2006, at 10:08 AM, Bruce D'Arcus wrote:
On Jan 28, 2006, at 10:43 AM, Bruce D'Arcus wrote:
I really don't care whether it's Python or Ruby, since both are
object-oriented, and both are easy to read.
At any rate, ultimately I'd like to see both citeproc-rb (think a
module that c
On Jan 28, 2006, at 10:43 AM, Bruce D'Arcus wrote:
I really don't care whether it's Python or Ruby, since both are
object-oriented, and both are easy to read.
At any rate, ultimately I'd like to see both citeproc-rb (think a
module that could be included trivially in rails apps for example),
14 matches
Mail list logo