> Then I create unit tests for the to-be-created implementations using > some mock objects framework for all dependencies. These test the work > interface contract as I drew it. >
Do you use easymock or something else for this, cause it seems that it does not test interfaces. Only if you have a implementation in place can you use easymock to test the interface contract. > Then I create trivial implementations (ie no I/O, no threads, no > external dependencies....no blahblah at all) that simulate what they > should be doing later on. I add implementation ideas on making things > work better in comments. > > Run the tests. Probably add more tests as my idea of the contract > solidifies. Modify the interfaces one or two times. Add in custom > exceptions. > > Coffee break. > > Then I start modifying the implementations to actually do what they > should be doing, rerunning the tests often. > > When things seem in order, I start writing up things like metadata, > config files, etc, and start doing integration tests (if you're using > Merlin, you use the AbstractMerlinTestCase, if you're using Fortress or > Pico, you just create and populate a container instance). This is often > a frustrating part as I manage to forget config file formats quite > often, but backed by all my running unit tests I can usually figure out > the issues. > > Coffee break. > > When all that works, I'll usually do another sketch (this time what > things actually look like), then refactor things bit by bit as I change > things in the sketch. Until I'm sort-of happy with the layout. > > This is usually when I make my first commit (so peers can review and so > I can go back and look at what on earth I meant in the first place). > I'll have a coffee break and talk to one of to those peers for feedback. > If no peer is available, I read slashdot instead. > > The next point should usually be to refactor the test cases into an > abstract test case that just tests the work interface contract, and a > subclass that runs the tests in the abstract case, plus a few of its own > (like for constructors), on the implementation. This is especially > important if you will have multiple implementations of the same > interface, since basic testing of other implementations just involves a > minimal extension of the abstract test case. > > I'm often too lazy to do all of those things though. In practice I'll > often get enthousiastic on an idea, then just write an implementation > immediately, add minimal tests that show it works, take a coffee break, > then start componentizing. But always regret it later because that's > actually more work. > > An interesting observation about the size of the subsystem I tackle at > once: it is limited to the size of the paper I'm drawing on. I used to > be much more productive in one of my old jobs: we had lots of A3 paper > lying around. But I think I produced more bugs too :D > > I'd round of with a joke involving paper and coffee, but can't think of any. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
