It tends to open up and cripple the classes even more than they were before.
-And hopefully encourage the development team to do something about it before it becomes too big a hassle.
The important point is that the supplied data can vary, and that has an impact on the structure of the concrete instance of the template.
This action is now a PicoComponent, honouring constructor based dependency injection. saveCheese method will hit the database.
I still haven't tried to run it over any other codebases, so it remains to see whether it is useful or not.
That would have been absolutely impossible without the extensive test suite we had built up by then.
Post-testing and post-mocking is actually quite evil.
NET and a Ruby port, and more in the pipe. The team's established practice is to extend the action and override methods that use objects that we want to mock out.
And tons of code too. The dupe method simply creates a new object graph similar to the one in the template, but substitutes all variables with the values from the hash.
I reckon it will take a few years before we see them changing. Many of the "mocks" in this codebase are not really proper mocks, apart from having the word "Mock" in their name. This involved some simple reflection logic and was implemented in a couple of classes. He also seems to ignore the benefits of TDD. If you do, you're not testing the real thing. But it's better than having to maintain a CheeseAction and a MockCheeseAction. The result of this is overly complicated tests, in addition to a false perception of what is being tested. This action is now a PicoComponent, honouring constructor based dependency injection.
Gavin and Hibernate rock. It's kind of blurry to me how we decided to go for constructors, as we were both drunk when we started TDDing the first lines.
He also seems to ignore the benefits of TDD. There are good and bad ways to do TDD.
NanoContainer or Spring are two frameworks that use this approach to instantiate complex graphs of objects composed of "variable data" from a configuration file.
Being able to refactor is essential in order to obtain a maintainable and well designed codebase.
After all, the overridden saveCheese method in the "mock" calls the superclass' method, right?
You will catch bugs sooner rather than later. He got this weird _expression_ on his face when I asked, and I couldn't quite figure out whether he was excited or depressed. At the end of the day that will bring us code that is easier to maintain.
But claiming that I have written a book about Excel VBA is just plain hilarious. Probably because I'm an XP head. He also seems to ignore the benefits of TDD. -A fairly common combination of technologies and patterns.
Send your code to Guantanamo! Another good reason to use them - and TDD in general - is to let good designs emerge more easily. There are probably some odd, unknown, project-specific scripts lying around in random places that can automate this, but I haven't seen anything reusable.
It tends to open up and cripple the classes even more than they were before. -Like always doing the simplest thing and continuosly refactor the code. -And hopefully encourage the development team to do something about it before it becomes too big a hassle.