Unit Tests (Design tests) or not...

When do you use unit tests - tests that test your design vs. tests that test the functionality of the app.

Unit test have good and bad aspects to them. The good stuff:
1) They encourage you to understand what your building at a microscopic level
2) They help with defect triangulation - a particular test should fail when a piece inside the system fails.
3) They encourage better design
4) They can cause you to write fewer functional tests - I find this is especially true around error handling, not sure about "calculation" business logic.

They have bad aspects:
1) They cause your design to be more rigid. Its harder to throw away design when it has a bunch of unit tests, because you must bring all the tests up to date as well. Some may be relevant and some may not.
2) They are far more fragile - I find myself maintaining them far more than the acceptance tests, often for things that are not interesting (renaming a variable/Constant).

In summary, we are experimenting with implementing them AFTER the design has solidified.

1) Get your functional test working - brute force (no unit tests, simplest thing possible)
2) Get some moretests working - brute force (no unit tests, simplest thing possible)
3) REDESIGN and Unit test once the design has become clear from the former examples.
4) Unit test when things get interesting

Hello

I guess this is an introduction. I'm currently leading my fourth agile project, and continuing to learn a whole bunch of stuff. Currently, I'm working with Colin Jones from CGI and Joseph King from Black Dog Co. Both really good people to work with, open to ideas and suggestions, and way smarter than your average bear.

We're working on a production accounting system for some large oil and gas companies in Calgary, with a team of twelve. Its a large team for an agile project, but the principles have scaled nicely for this team.

For those of you who are really agile, you may be asking yourself - is he really agile? Well that's an answer you can derive for yourself.

1) Our customers are on site
2) Our requirements are expressed through stories - verbally
3) Our customers write acceptance tests
4) We code our tests before we write our code
5) We check in almost everyday - all your tests must pass for you to check in
6) We release frequently (daily to QA, monthly to the customer)
7) We do small slices of functionalty from end to end
8) We have a product backlog
9) Our architecture and design is evolving
10) We haven't got one class or component called "Framework"