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.
We alternated the keyboard rapidly and made the test pass. This is because with TDD you don't write code you "think you might need".
If your test is too complicated, you're not doing it right. Probably because I'm an XP head.
Check out QDox Attributes! The team's established practice is to extend the action and override methods that use objects that we want to mock out.
You can read my full bio here or just this shortened version.
NET, sometimes it's Excel or PHP. Much of the nice modular design we have today is owed to him.
NET, sometimes it's Excel or PHP. The package scope is even com.
The result of this is overly complicated tests, in addition to a false perception of what is being tested.
This can incur some percieved overhead in the codebase, as the developer will now have to maintain both a CheeseDao and a HibernateCheeseDao.
Mocking is also an essential part of the whole TDD concept. -A fairly common combination of technologies and patterns. After all, the overridden saveCheese method in the "mock" calls the superclass' method, right?
HURRY TO SEE SELECTION! Oh well, leave'em here then. He got this weird _expression_ on his face when I asked, and I couldn't quite figure out whether he was excited or depressed. Learning Ruby has opened up my eyes about what OO, agile development and extreme productivity should be like.
Or is there a way to launch IDEA from IDEA?
I had known about TDD for a couple of years, but hadn't yet had that epiphany where it fundamentally changed the way I think about code - and religiously follow the practice. To make it work Microsoft had to create Managed Extensions.
That would have been absolutely impossible without the extensive test suite we had built up by then.
Seeing this will make it harder to ignore problems related to build time.
Oh well, leave'em here then.
Jon quickly joined the project and has since been an important contributor. I was ruthelessly refactoring the entire codebase to improve the design.
At least at the time of the invention of the antipattern.
Specifically, if the superclass is refactored, there is no guarantee that the test is still valid.
Knowing when you're done saves time.
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.
While this is a noble goal, it is not the only good reason to use mocks.
-And whether it is something anyone would actually want to use. Having a well designed codebase saves time. You will catch bugs sooner rather than later.