Message-ID: <337077175.1377.1427439609302.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1376_1086181022.1427439609302" ------=_Part_1376_1086181022.1427439609302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Aslak and I were brought on to a project with the task of refact= oring a legacy codebase. A complex application with approximately 30 thousa= nds lines of code, written over a 2 year timeframe by many programmers. The= code worked as intended and was actually a success compared to all previou= s efforts to accomplish the same sort of functionality. The team is som= ewhat agile and uses CruiseControl for automated builds.=20
We had some clear directives from the client:=20
At first glance, the code didn't look too badly written and Clover was r= eporting over 60% coverage from approximately 1100 Junit tests. Hmm... Divi= ng into the test suite usually seems like a good starting point to figure o= ut where to start.=20
To my dismay, there were some serious issues with the way that the unit = tests were written. I should say so-called unit tests, cause there= were some major problems to address:=20
The majority of those tests weren't actually unit tests at all. Sure, th= ey all extended JUnit TestCase, but most of them did some sort of file I/O,= many included calls to Thread.sleep(), and during their execution there wo= uld be about 20-30 AWT windows popping up and flashing stuff in my face. As= a matter of fact, they were system tests masquerading as unit tes= t.