testingReflections.com - refactoring

Short and long game thinking, tests driving design and CRAP metrics

Thu, 28 May 2009 05:59:56 +0100

Kent Beck recently posted To Test or Not to Test? That’s a Good Question on the complex “theory versus practice” issue of always automating tests, where he states,”Then a cult of [agile] dogmatism sprang up around testing–if you can conceivably write a test you must”. By classifying projects into long game and short game, he argues that ROI becomes a major issue on whether a test stays manual. He says “Not writing the test for the second defect gave me time to try a new feature”, but several people commented that this was a technical debt tradeoff, and Guilherme Chapiewski noted he had done the same thing with a Proof of Concept that went live then he had to rewrite major chunks later. It is interesting that this ROI discussion is reflecting the experiences of the pre-agile functional automation community. Back in November 2001 (Wow! Long time ago!!), I posted to the Agile Testing list some considerations for not automating . While many of these were from the context of two separate development teams and the automaters using expensive test tools, the risks of incomplete automation and insufficient ROI dominate. The benefits of having the same people both develop the code and the tests are great, and beyond my experience when I wrote that post.

I think the ROI issue for code-based tests will go away over time. Much of the creation of code-based tests is mechanical. Just as programming languages replaced assembler and took care of fiddly details (what registers to use, low level comparisons etc) and build utilities replaced simple text file include statements, I think that soon it will be standard practice to have tool-created unit testing to handle mocking, dependency injection and assert-based testing. Mocking was originally very manual, then tools were developed. Dependency Injection was very manual,then tools were developed. For assert-based testing, we’ve already seen Agitar’s tools , zentest and now pex amongst others. I think these tools will become standard, just as coverage tools are now standard in IDEs when they originally were luxuries costing tens of thousands of dollars. Another variation of this is tools like Celerity recently blogged about by Jeffrey Frederick. Celerity is a fast way to run GUI web tests, but could be handled as a mechanical translation not a manual one. Some meta language could generate Celerity and selected browser tests in a single step.

Mechanically generated tests are cheap to produce and overcome ROI issues. However, they only reflect the current code. The benefits of test design infusing the coding approach are missing. If tests are not being automated for whatever reason, some analysis of the refactoring risk should be done, at least to know where and what the error-prone code is. One way of doing this is using the Agitar-created CRAP metric , which Bob Martin recently blogged about as a way to keep design clean. While I currently believe all code should be created test first wherever possible, techniques like the CRAP metric can highlight the complicated bits for refactoring where possible. While it may be a great intellectual challenge, there is no need to refactor a complex industry standard algorithm. [Aside: is there an inherent advantage to doing test first design all the time? Perhaps, just as renaissance masters only painted and sculpted hand and faces and left the rest to their workshop staff, we only need to focus on core functions for test first and do the rest test last?]

As Kent says,”By insisting that I always write tests I learned that I can test pretty much anything given enough time.” Time is often a rare commodity, so Kent argues compromises are often needed in short goal projects. As Ron Jeffries said in a comment on Kent’s post, “My long experience suggests that there is a sort of knee in the curve of impact for short-game-focused decisions. Make too many and suddenly reliability and the ability to progress drop substantially.” I hope that advancements in mechanical generation of tests don’t push us into a short game perspective, impacting the use of hand crafting tests to drive design. At the same time, metrics that can be run as part of the build to highlight areas for refactoring on all projects are proving valuable (and I’m looking forward to state coverage ). By any measure, these are interesting times we live in. Long live long game thinking!

Legacy Refactoring Series (part 1)

Tue, 26 Apr 2005 07:25:55 +0100

In its current state, the codebase is not as healthy as it could be. There are three classes in this system. The first class is the GUI, which is pretty simple and self contained. There might be some logic in it that could be refactored out into a Controller-type class, but I havent looked at it closely enough yet to know. In the same file as the GUI is the worker method for the thread where all the work happens. Not sure if I like this or not yet, but Ill visit it at some point. There is a class called Assembly2UML which is the main worker class for this tool. This class is responsible for finding all the types and their relationships, and it has one real method in it, Serialize, and its 200 lines long. Well revisit this Serialize method shortly, as it is our original target for refactoring. Finally, there is another file called XMIServices, which houses both the interface IUMLFormatter and its derived type XMIFormatter. It is the responsibility of this XMIFormatter to be called occasionally from the Serializer to output the growing XMI model as it forms.

Introduction to Refactoring to Patterns

Mon, 14 Feb 2005 06:21:29 +0000

Refactoring software by hand can be a real pain. So why not just automate the process? In this chapter, Joshua Kerievsky explains the whys and hows of refactoring, and why you shouldn't trust that automated refactoring program.Author: Joshua KerievskyPublished: InformIT, January 28, 2005Excerpted from Refactoring to Patterns

Refactoring Thumbnails [PDF Slides]

Tue, 14 Dec 2004 07:02:54 +0000

Series of slides showing how Refactoring Thumbnails are used to express the evolution of a design. Explains the sequence of high-level refactorings, and presents intermediate stages. Author: Sven GortsPresented: XPDay Benelux 2004See also: refactoring.be

A Taxonomy for Bad Code Smells

Mon, 06 Dec 2004 06:09:41 +0000

This taxonomy aims to provide better understanding of Code Smells and to recognize the relationships between smells. The five types of smells are: Bloaters, Object-Orientation Abusers, Change Preventers, Dispensables and Couplers, and indicate a Refactoring session may be in order.Author: Mika MäntyläPublished: 2004(via Udi Dahan)

What is refactoring and why do you need it?

Sun, 24 Oct 2004 23:26:02 +0100

Every day, software developers make decisions that they later regret. They may be tiny decisions, such as the name to use for a variable, or they may be major decisions such as the metaphor to use for a new application, but no one gets it right every time. Even the most experienced, skilled software developers would like to be able to revisit earlier decisions, because it's the nature of their work to make decisions based on limited information, then to learn more over time.