Test-driven development and the ethics of quality

By Jennette Mullaney, Associate Editor 12 Mar 2008 | SearchSoftwareQuality.com

Software quality news and advice Digg This!     StumbleUpon     Del.icio.us

Software quality is an ethical concern, one that requires discipline and rigor from the developer and the tester. Robert Martin, founder, CEO and president of Object Mentor Inc., recently explained his methods for creating quality software to an audience of testers and developers at FutureTest 2008.

TDD is probably the single most important practice discovered in the last 10 years. Robert Martin Founder, CEO and president, Object Mentor Inc.

Martin, known as "Uncle Bob," did not mince words as he instructed his listeners to respect their work and their product. "We as software professionals have a craft," he said. "It was not always so."

Rather than relying on the ad hoc methods of the past, testers and developers should use today's knowledge to create better software. Concepts of modularity and structure and practice such as unit testing and agile development are just a few of the innovations modern software professionals may turn to, Martin said.

Modern software professionals have also picked up a few bad habits over the years, among them an unfortunate lack of discipline, Martin said. He cited pressure within the software industry to "violate discipline" and create a "big, messy wad of code."

Martin related a story about a project wherein the developers did not have a deadline. The developers rushed anyway and presented Martin with their work. "They thought I would be pleased by this mess," he said of the code.

Short iterations, gradual refinement
Martin advocates short iterations of one or two weeks that result in deployable software. With iterations of a month or two, too much can go wrong, he said.

In order to fit design, implementation and testing into such a short iteration, practitioners should not wait for the entire set of requirements to be defined. Martin proposes avoiding the "document-driven, specify-then-build approach" decried by noted computer scientist and The Mythical Man-Month author Frederick Brooks.

Just as requirements definition should not block software professionals from completing an iteration, neither should heavy architecture.

"Don't fall into the trap that architecture solves everything," said Martin as he flipped to a slide warning his audience to "Avoid turgid, viscous architecture." Thin and simple architectures that solve the problem at hand are a much better alternative, he said.

Also from FutureTest 2008 Software testing offers big ROI Software testing saves money and calculating the return on investment is easier than you think, Rex Black told his audience at Future Test 2008.

With these blockages out of the way, developers and testers should work in cycles of successive refinement. Incremental improvements help stave off "rot" in code and tests. When there is rot, testers and developers should avoid the impulse to throw it away and redesign. "Face the mess and clean it up gradually and slowly," he instructed.

Features should be added gradually as well, suggested Martin. Begin with minimal architecture and then widen feature by feature, he said. Once this set of features is working, widen some more.

All of this progress can be derailed if developers and testers move too quickly to incorporate quality.

"Rush a software project and it will die," warned Martin. Bad code and bad tests stay around forever, he said. "The only way to go fast is to go well."

Test-driven development
It is no coincidence that the practices Martin outlined are consistent with those of test-driven development (TDD). Martin is an enthusiastic proponent of TDD and wears a green wristband emblazoned with the words "TEST FIRST." According to Martin, TDD is "probably the single most important practice discovered in the last 10 years," with regard to software development.

Ideally, TDD results in no bugs and 100% code coverage. QA engineers who follow disciplined test-driven developers should find no bugs to clean up, Martin explained. Instead, QA should be incorporated at the beginning of the SDLC, writing tests, he said. In addition, developers should run unit tests to cover every single line of code. "It seems absurd," said Martin, "but it's not."

The burden of so much testing may be eased through the liberal use of automation. "Why do we want hordes of people doing what machines should do?" asked Martin as he stood in front of a slide that was bare except for the phrase "Manual Test Scripts are Immoral." If it is scriptable, he said, it should be automated.

Besides being good for software, Martin finds running all of these tests until every one passes to be "extremely addicting."

"Developers are developers because they got something to work once," Martin said. As test-driven developers run test after passing test, they get that feeling of accomplishment "every five minutes."

Sound Off! -   Be the first to post a message to Sound Off!

Tags: Test-driven development (TDD),  Software quality management,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us