In a former employers, there was an employee who we will call Kevin McCallister in order to protect the guilty. In any case, for various reasons, I ended up having to maintain some of the code that Kevin wrote...
I ran all the test cases and measured the code coverage, it seemed high and there were lots of test cases... but bugs a plenty kept on hitting me... I finally found the answer in one test class... which looked a little something like this:
/**
* Tests the FooBar class * @author Kevin McCallister */ public void FooBarTest {@Testpublic void smokes() {try {new FooBar().method1();} catch (Throwable t) {}try {new FooBar().method2();} catch (Throwable t) {}try {new FooBar().method3();} catch (Throwable t) {}...try {new FooBar().method15();} catch (Throwable t) {}...try {new FooBar().method30();} catch (Throwable t) {}}@Testpublic void method1DoesSomething() {// write later}@Testpublic void method1DoesSomethingElse() {// write later}@Testpublic void method1DoesAnotherThing() {// write later}@Testpublic void method1DoesSomethingWhenFoo() {// write later}@Testpublic void method1DoesSomethingWhenBar() {// write later}@Testpublic void method1DoesSomethingWhenBarAfterFoo() {// write later}@Testpublic void method1DoesSomethingWhenFooAfterBar() {// write later}...}
To make myself clear, there was one method at the top that called every function and would never fail (gives you the code coverage) and a couple of hundred empty test methods that did nothing but had names that sounded like nice test cases...
So there you have it, how not to write unit tests
So there you have it, how not to write unit tests
I like how they caught Throwable, not Exception. Shows some kind of understanding that they are maximising their chances of under no circumstances failing a test.
ReplyDelete5 Stars. Would read again.