Having a well designed codebase saves time.
Post-testing and post-mocking is actually quite evil.
There are good and bad ways to do TDD. Gavin and Hibernate rock. I was ruthelessly refactoring the entire codebase to improve the design.
Then what's more natural than moving the blog too? Post-testing and post-mocking is actually quite evil.
This will in the long run lead to SHORTER development time.
I just wanted to argue that TDD does not slow you down. How do you know whether that is needed or even if it's going to work? PicoContainer was now a well-established project. Many of the "mocks" in this codebase are not really proper mocks, apart from having the word "Mock" in their name. Or is there a way to launch IDEA from IDEA?
How do you know whether that is needed or even if it's going to work?
I was ruthelessly refactoring the entire codebase to improve the design. saveCheese method will hit the database. Calling the CheeseDao. The test fixture should be simple and the assertions few.
Its class is generally an implementation of an interface or a subclass of some class, either generated dynamically or statically coded. The test fixture should be simple and the assertions few. Mocking is also an essential part of the whole TDD concept. This action is now a PicoComponent, honouring constructor based dependency injection.
That would have been absolutely impossible without the extensive test suite we had built up by then. This can incur some percieved overhead in the codebase, as the developer will now have to maintain both a CheeseDao and a HibernateCheeseDao.
Being able to refactor is essential in order to obtain a maintainable and well designed codebase. But it's better than having to maintain a CheeseAction and a MockCheeseAction. The good one is to keep the tests simple. Knowing when you're done saves time. If your tests are simple, so will your code will be.
Before I delve into the details, let me recap some simple mock essentials.