test objects design

I understand the wiki. It’s a nice example of a front end to FIT. Of course someone has to be writing Fixtures, right? I am not clear on who writes them but I think it would be developers hooking up tests to invoke their methods. So far I am going over examples provided. What I understand is that I write Tests against the Fixture code which is piping it to my App code. So if Tests are in Wiki then where is Fixture code then? Plus will Fixture code be written first? or do I first write tests, then create Fixture code?

There are 3 types of Fixture tables

1. Column = If I give you this and that then will I get that other thing back?

2. Action = calling methods and getting stuff back? (need to get clear on that)

3. Row = run queries?

As a sidenote: I love this from How to Kill a Software Project Fitnesse page

Problems!

At some point, usually late in the project, the team discovers that among other problems, they are finding one or more of the following problems with the features being delivered:

• They are not exactly what the customers/analysts/product managers think they asked for.

• They are not exactly what those folks wanted or needed.

• They are not useable by the system’s eventual users.

• Subsystems cannot be integrated with one another, because their interfaces are incompatible.

I think when Management steps in it makes very little difference because Functional Design needs to be recreated at this point. I used to say to my manager “This will need to be designed, we can do it now or 5 minutes before going live at 2 in the morning where everybody is tired. So when do you want to do it?”

I am trying to connect the dots with Fitnesses; I just don’t get how fixture can be a living doc for testers and customer; and what do developers get out of it? I guess it’s time to join fitnesses mailing list and snoop around the archived conversations. Some 1000 members and almost 4000 messages since Feb 2003. Looks like going strong.

Technorati Tags: Fitnesse