I've started to think about what it would be like to develop the view part of a
webapp using the Ajax concepts.
This is because you can't know whether your refactorings will break something
without tests.
I just wanted to argue that TDD does not slow you down.
This action is now a PicoComponent, honouring constructor based dependency
injection. And tons of code too. But claiming that I have written a book about
Excel VBA is just plain hilarious.
But it's better than having to maintain a CheeseAction and a MockCheeseAction.
Gavin and Hibernate rock.
I'm sure you have read all the fuss about it already.
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?
More often than anything else it's not even about programming.
After all, the overridden saveCheese method in the "mock" calls the superclass'
method, right? The result of this is overly complicated tests, in addition to a
false perception of what is being tested. Post-testing and post-mocking is
actually quite evil.
NanoContainer is also an interesting sister project that adds scripted
configuration using a multitude of script languages, as well as integration with
WebWork, Hibernate and much more.
This involved some simple reflection logic and was implemented in a couple of
classes.
It tends to open up and cripple the classes even more than they were before.
Seeing this will make it harder to ignore problems related to build time.
Post-testing and post-mocking is actually quite evil.
I just wanted to argue that TDD does not slow you down. saveCheese method will
hit the database. Paul and I started it right after I moved to London to start
working for ThoughtWorks. Its class is generally an implementation of an
interface or a subclass of some class, either generated dynamically or
statically coded.