Despite the invention of so many different types of software testing methodologies, many in the industry are still sticking to the tried-and-true method of test-driven development, or at least some form of it.<\/p>\n
\u201cLike any other methodology, I think there seems to be some pretty significant variations between TDD as it\u2019s described in books and what\u2019s actually practiced,\u201d said Rex Black, president of RBCS, a software, hardware, and system testing consulting group.<\/p>\n
According to Black, the textbook definition of TDD is that it is the process of writing small tests that express some sort of functionality that you expect the software to accomplish. You then run that test before writing code to confirm that it fails, then you write software to make the test pass. As soon as the test passes, you move on and repeat that step again, Black explained.<\/p>\n
That definition is the one advocated by Kent Beck and Martin Fowler, proponents of TDD. But not everyone who says they do TDD is doing it the textbook way, Black explained.<\/p>\n
\u201cI see some of that with clients, but not a lot, to be honest with you,\u201d said Black. \u201cSome of my clients will talk about doing TDD and sometimes, some of the people, some of the developers say that they mean they are doing exactly what Beck and Fowler and some of the other advocates of TDD recognize as TDD. A lot of the time, they\u2019re doing things a little differently.\u201d<\/p>\n
According to Black, another one of the variations in definition has to do with the size of the test. In Beck\u2019s description of how TDD should work, the tests are very, very small. But often what people do is write a test for a number of different functions all at once. \u201cI think what Beck and Fowler would say if they saw that would be \u2018no, that\u2019s not right. You should break it down into single tests or steps and write the tests and the code step-by-step,\u2019\u201d Black said.<\/p>\n
Arthur Hicken, chief evangelist at Parasoft, explained that while TDD is often interpreted as code-based unit testing, it is also sometimes viewed as something akin to a service API in that you have something that does a service and you have a definition file. \u201cBefore you ever write code, you write this definition of what it\u2019s supposed to do, and then you can use tools against that definition to instantly generate tests,\u201d said Hicken.<\/p>\n
Another variant that gets confused with true TDD is people who write unit tests after they write the code.<\/p>\n
Even if people are mislabeling something as TDD when it is not, maybe that\u2019s not such a bad thing, Black explained. \u201cFrom my point of view if I see developers producing automated unit tests and achieving 100 percent state and branch coverage and including those unit tests in their automated build and deployment systems, then I\u2019m happy,\u201d said Black.<\/p>\n
Hicken sees TDD as a broad spectrum. The pure side of the spectrum is where people are coming up with requirements first, coming up with a unit test, writing the code, and writing exactly the right amount of code, he explained. On the other side of the spectrum are people who write unit tests at the same time as writing the code, said Hicken.<\/p>\n
At the pure end of the spectrum, one of the benefits TDD provides is that it prevents people from over-writing code. \u201cWhen you write code you\u2019re supposed to write exactly how much code you need to pass the test and not a single line more,\u201d said Hicken. \u201cAnd so it keeps people from polishing the code or other things like that. You write what you\u2019re supposed to and you move on.\u201d<\/p>\n
According to Black, developers can go back in and polish the code after it has been written and the test has passed.<\/p>\n
According to Hicken, another benefit of TDD is that it forces developers to think about the outcome before developing. The code ends up being more maintainable and testable because they are thinking about what is supposed to happen when writing the test. \u201cIt kind of changes the mindset of people because they have the end in mind when they\u2019re programming,\u201d he said.<\/p>\n
Hicken explained that the testing methodology TDD is most often compared to is behavior-driven development. The main difference is that TDD is focused on developers, while BDD is focused on the testers and the requirements.<\/p>\n
With TDD, the main question should be whether the code was built right, whereas with BDD the question is whether they built the right thing, Hicken explained.<\/p>\n
Even as more companies seem to place their focus on building for their users, which aligns more closely with BDD, TDD is not going away. \u201cI would say that almost every client I\u2019ve encountered this year that was interested in the one, was also doing the other,\u201d said Hickens.<\/p>\n
Hicken explained that companies may do BDD first if they are finding that they\u2019re not building what people want or not getting functionality fast enough, but he does not expect people to throw away one for the other.<\/p>\n
Like any new methodology or technology being brought into an organization, it needs to have buy-in from the top in order to work, Hicken explained. It\u2019s crucial to have management on board and to be able to train people to write good unit tests. \u201cI\u2019d argue that over the long haul, the cost of creating a unit test is much less than the cost of maintaining a unit test,\u201d Hicken said.<\/p>\n
\u201cIt\u2019s easy to create a unit test, but to create one that really answers the question, \u2018what does this code do? If the test passes, what does it mean? If it fails, what does it mean? And if it fails, what went wrong?\u2019\u201d Hicken said. Training developers to be able to answer these questions is key.<\/p>\n
Arthur Hicken, chief evangelist at Parasoft, details the benefits that Parasoft brings to test-driven development
\n<\/b><\/p>\n
\u201cThere are couple of big areas that we help at. And at the purest unit test level, we\u2019re looking at code unit testing. If people are doing new code, they won\u2019t use us as much as if they\u2019re looking at legacy code. Suddenly if I\u2019ve got a TDD initiative, I\u2019ve got some code that\u2019s new and I\u2019ve wrote the test first, I can execute those tests inside of Parasoft\u2019s environment. But with that legacy code, we can use our unit test assistant to help create\u2014very rapidly\u2014unit tests that are actually good, maintainable, have a good set of stubs and mocks around them, are very easy to execute so they\u2019re meaningful and maintainable all at the same time. Now again as I mentioned earlier, I like to think about the service API as a unit, and in that case we can take our SOAtest product and read the definition and quickly produce a sequence of tests without any effort at all really. And then the developers can just take that and start coding until the APIs work. I would argue that as an API programmer, API is probably a more meaningful unit than a random individual file is. Those are probably the biggest benefits that we have there.\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"