Dan had a business object. It represented a user’s Dashboard, a screen which had a collection of widgets that displayed some user specified data. The application needed to be able to compare these Dashboard objects to tell if two instances were the same, so someone had written a custom Equals method, back in the Cambrian epoch.

As often happens, the business requirements mutated. Dan added a thumbnail property. Now users could browse a collection of Dashboards and get a sense of what they might look like without actually switching to that Dashboard layout. Two otherwise identical Dashboards might have different thumbnails, so Dan didn’t add code to the Equals method. To make the rules quite explicit, he added a comment, instead: previewImage should NOT participate in business equals. He also added appropriate assertions to the unit tests.

Dan checked in those changes, and moved on to the next new feature. He had barely started working on it when his boss, Vince, started screaming. “Something is broken! The Dashboards don’t work. Dan, you were working on the Dashboards. Didn’t you test the code?”

Dan had tested the code, but maybe he made a mistake. He promised Vince that he’d look. It didn’t take long to figure out what the problem was. 

//previewImage should NOT participate in business-equals - Dan 
//added previewImage check - Vince 
if (! this.previewImage.Equals(other.previewImage)) result = false;

Vince had also “corrected” the unit test and removed Dan’s assertions. Dan reverted Vince’s changes, and added a new unit test, clearly named previewImageAbsolutelyShouldNOTUnderAnyCicrumstancesParticipateInBusinessEqualsEver. Dan confirmed everything was working and checked those changes in. He also had a long conversation with Vince about why what Vince had done was wrong, and why Vince should not change his developers’ code without talking to those developers.

A few days later, Dan was stricken by a sudden sense of déjà vu. Vince screamed, “Something is broken! The Dashboards don’t work. Dan, you were working on the Dashboards. Didn’t you test the code?”

Once again, someone had added previewImage to the Equals method. Even worse, the unit test clearly named previewImageAbsolutelyShouldNOT… had been modified so that it tested that previewImage was included in the Equals method. The test’s name was left unchanged.

Dan fixed the code, again. He had another conversation with Vince that explained why previewImage should be left out of the Equals method. He fixed the unit tests. Since insanity is doing the same thing and expecting different results, Dan went the extra mile. He went and found an obscure unit test that had nothing to do with Dashboards. He added assertions to confirm that previewImage wasn’t part of the Equals method. When the assertion failed, the error he had it return stated:

STOP. STOP. What the hell is wrong with you, you frickin’ pantload. You have just made a terrible mistake. Again. Put down the mouse, remove your hands from the keyboard, and step away from the computer. Call x5316 before doing anything else.

Dan checked that in, and got back to dealing with mutated features. It didn’t take long before he got a phone call from Vince. “Dan. I am getting the strangest error message from our unit tests. Something is broken…”

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!