Google launch their Cloud Test Lab today. I’m reminded of how I first learned the value of qualitative user testing and how I forced my employers to take notice too…
Between 1997 and 2000 I managed an Internet café in West London, for a startup who also ran a small web-based email service. Continue reading Guerilla usability
If you want to write a unit test which verifies that something implements a particular interface, or extends a particular class, here’s how…
Continue reading How to verify that something implements an interface with Mockito
Since I’m not sure whether I have indeed invented a new design pattern here. So, alternative titles for this post include:
- Dependency Injection without a Dependency Injection framework
- Why misuse of the default namespace for tests is pure evil
- How to make your code more testable without completely messing it up
Continue reading Dependency Injection by Extension pattern
I recently had a bit of a shock while reviewing someone’s code, finding the following line in one of their unit tests:
Where: sut is their System Under Test and verify is the part of the Mockito Flex framework.
Exercise for the reader: What’s wrong with this picture?
The answer: You cannot expect Mockito to verify that something was called on anything that isn’t a mock! How the hell is it supposed to know?
At least, if attempting to stub a method of a non-mock, you’ll get a handy error telling you not to be so damn silly. But, in this case, the verify will always work. So the test will pass, but it isn’t actually verifying anything! Where do I start with the bad? This is the worst kind of test, since it provides a false sense of security on the robustness of a system. Thankfully, all the tests in this codebase had called their System Under Test either sut, _sut or SUT, so it was pretty easy to get Hudson to mark a build as unstable if it finds such madness.