Reviving Dinosaurs: TDD vs Test-Last

Simon Stålenhag - Tyrannosaurus (http://www.simonstalenhag.se)

“Be careful with the following code - I only proved that it works, but I did not test it” Donald Knut

The “First Test” technique (Test-First Design, further TFD) appeared along with extreme programming (Extreme Programming, then XP , by the way, this abbreviation is in no way connected with Windows ) and is one of the main approaches of this methodology. The first book mention of this technique was in Extreme Programming Explained 1999 K.Beck.



At the core of technology is a simple idea - before you do something, write something to this test .

“Never write code without a denial test.” Kent Beck

Later, the TFD technique evolved into the Test-Driven Development (TDD) technique, which took its place in the list of XP approaches.

1. Development is conducted in short cycles.
2. The implementation of the function is preceded by a refusal test (red-green refactoring) .
3. Failure test only one .
4. The implementation of the function should be as simple as possible and sufficient for passing the test (closely related to the principles of KISS and YAGNI ).
5. After passing the tests, we begin ruthless refactoring (at this stage we get rid of duplicates, it is closely connected with the DRY principle)

')


I will not retell here the wonderful work of Kent Beck , for those who want to understand the TDD approach in more detail the direct road to the store behind this book ( Test Driven Development: By Example 2002 K.Beck ):

Is TDD not working?

TDD is a dinosaur. But this is by no means kompsognat, it is rather an apatosaur. Not less. Many years have passed since the description of the technique. For information technology, this is really a long time.

The most progressive people in the world of software development have recognized and still recognize that TDD is a very effective tool in the programmer’s arsenal. It’s not a silver bullet , but time has proven it works. My humble opinion that developing through testing is an ingenious technique.

However, the situation of Belarusian (or any other similar) outsourcing in this part is sad. We never had TDD. No one ever chanted his ode to him. On the contrary, I constantly heard something else.

In 2010, I joined the staff of QA department of the company * instinctools. When I started to dive deeper into automation, I started asking questions: “Why don't our developers write tests?” The answer was probably the obvious one — the customer does not pay money for it.

The world, like Belarusian outsourcing, is evolving, now even the newly-made junior developer or customer far from programming knows that tests are necessary. It is difficult to imagine the auto industry or the food industry without testing (everyone would then be poisoned by food or broken on the roads), although this could also be saved. But if everything has already come to the point that it is necessary to write tests, how to do it exactly - not yet.

It is expensive. It does not buy the customer. We do not have time for this, we know that this is good, but we have too tight deadlines. This functionality will not be able to test this approach. This only works for unit tests. Typical answers to the question: “Why not TDD?” .

And at the same time, everyone writes tests all the same, but only do it in the style of Test-Last .

We don't have time for this.

Taking the Test-Last path, the developer loses a bunch of TDD benefits.

Time is increasing. It is a fact! I don’t know why, but people think TDD will take more time. However, when the Test-Last programmer evaluates the task, the question immediately arises in his head, and how many more should I throw in so that I can cover it all with tests and technical documentation .

Test-Last is, in fact, a step back to the cascade model. After you implement all the functionality, you will not be able to achieve full test coverage, since the tests will not be cross-cutting. Your testing will be superficial, I am sure you will even adapt your tests to already written code. Attempts to test in depth, will take time for the implementation of the stubs.

Therefore, to test the encapsulated mechanisms, you are likely to wave your hand.



In contrast to this technique, you can start using TDD. Thanks to TFD and end-to-end testing, the coating will aim for 100%. Developing a function, you will go through two stages: interface design and implementation . At the test writing stage, you need to understand what the interface of your function will be, what it will receive at the input and what it will return. What will be the format of input and output data. Designing the interface and writing a refusal test, you write the simplest implementation, the limitations of which are already specified in the test. This is the path to simple and readable solutions. You will only need to describe the function in the project documentation.



And you can definitely say that at the beginning, you are unlikely to win in time. But from function to function, from project to project, the situation will change. You will get your hands on and testing will no longer be a separate development stage. It seems to merge with her. Those. it will be just development. Automated testing is not added to the assessment as a separate item, it is already embedded in the coding assessment.

“Focus on quality, and performance will come next.”
Capers Jones, from the book Mythical Man-Month 1975

Take time to debug and launch the application for verification. Debugging and verification of the implemented function is done through tests. By the way, this is the fastest way.

A couple of months ago, I sat together with Dima Santotsky (our GUI-developer) to implement a graphic component for editing the project's essence in the program being developed. Before that, he did not work in this style. From the beginning to the end of the implementation (this is exactly the logic, there was no layout), we switched only between the console and the IDE. As a result, Dima noticed that we opened the browser only once, at the very end, for the control check of the functional. This is really magic.

We did not collect the client part after each change, we developed it through tests.

Over time and everyday practice, the cost chart will look like this:



However, I see that few of us want to invest in it. Because of the outsourcing model, I came across many companies and customers, I know what I'm talking about, and this is not about anyone in particular. Do not take on a personal account. At the same time, I believe in individual teams of programmers who actively apply this approach.

Archery is not a simple matter. If you give it to you, you will hardly fall into the bull's eye. Need a workout. I remember how I first tried to shoot, the arrow flew somewhere completely past. The instructor was afraid that I would not overwhelm any fisherman.

Riding a car after the first lesson in a driving school is also unlikely to succeed. The same with TDD. From turtle races, over time, through training, you can get to Formula 1.

This only works for unit tests.

Integration / System Tests: I / O-First

The 2014 HYIP around “TDD is Dead” is attractive. I admit that there must be compromises. It is extremely difficult to emulate a video stream in tests (especially when there is still no implementation of the function that processes this stream). Or, for example, to observe the approach when testing security ( security testing ). Information technology is developing rapidly. Augmented reality, blockchain, computer vision - before automation there are a number of challenges. But I beg of you, if you implement a simple server with CRUD operations, then it will be easy to write integration tests in TDD style. You know what HTTP verb is needed for this or that operation, you know what status should be in response. Consider the format of the HTTP response. And the failure test with a 404 error is ready. Now proceed to the implementation of the end point. No need for excuses and complications from scratch. In the case of system tests, it is important to determine the input and output data, this is the most difficult, then the process is no different from the unit tests. On the subject, there is a series of video meetings from the authors of the approach with the opposition in the face of DHH .

E2E: PageObject-First (POF)

Acceptance criteria most often take the form of functional or end-to-end tests. And in this part, almost all developers do not understand how to write a test for a page that does not yet exist. Before my eyes immediately tons of HTML markup and CSS-layout. This is a common mistake for newbies. Important page functions, controls, content, and not markup and layout. Just as the designer creates the page layout, the developer must describe the page with a PageObject template based on the design or design. This is the stage of this design. You decompose the page, breaking it up into elements and describing them with class methods. I would call this PageObject-First technique, and remember, the test is refusal, we do not need to know at this stage the specific ways with which we will find the controls, they are implemented later. In this part, you can still develop in the style of TDD. There is even a well-established name for this practice: “Development based on acceptance tests (Acceptance Test – Driven Development / ATDD)” . There are other variations (I think that such abbreviations can be riveted every day, the essence is the same):

• “Development based on customer tests (Customer Test – Driven Development / CDD)”
• “Development based on user history tests (Story Test – Driven Development / SDD)”

It is expensive

Tests should be on all fronts and rear, but there should be common sense in everything. Automation is not a panacea, it should not get carried away. We must understand that most of the tests, and this is modular, the developers write. The share of automation testers is much smaller. Of course, everything is based on a dedicated budget, the customer rules the ball. In this case, it is always better to be guided by the testing pyramid .



How else can you save? Let's take time to document, but at the cost of what? And why not make the tests documentation?

A new (actually not so new) expansion of the TDD approach solves this problem. Having incorporated the best principles of Domain-Driven Design by Eric Evans, TDD evolved into “Behavior-Driven Development / BDD or Specification-Driven Development / SpecDD” “

Dan North first described this approach in 2006 , presenting it later at a conference in 2009 in London. He also created one of the first frameworks based on this approach. The idea is in the title. And let's turn our tests into a specification. Those. now, when we write a refusal test, we do it through DSL (Domain-Specific Language) , in passing describing the behavior of the function being developed in a language accessible to all.





This great idea began as early as 1987 in Perl in the form of Test Anything Protocol (TAP) . One of the first implementations of human-readable test results, in fact, reports.



The BDD approach has turned tests into documentation, and into a human-readable and easily understandable report for a manager or customer. This idea is simple and no less ingenious than TDD.

Test-Last

So what about Test-Last? Is this a mossy story? Waste junk to be thrown away?

I do not think so. For me, this is an integral part of TDD. It sounds strange, doesn’t it? Yes exactly. I consider Test-Last a null step in TDD . It is with this technique, I advise everyone to start. After all, everything is relative. Only those who worked in this style, and later switched to TDD, can realize the full value of Kent Beck's ideas. A young Jedi needs to be on both sides. If you are currently working in the style of Test-Last, then continue. I'm serious. Try to achieve the fullest possible coverage, isolate the tests, write plugs and try to reach the most hidden functions. When evaluating and planning, estimate by eye how long it will take to implement the tests.

The new project, try to start developing in the style of TDD.

***

If you have any comments or additions, I will be glad to see them in the comments or write to artur.basak.devingrodno@gmail.com