d

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore.

15 St Margarets, NY 10033
(+381) 11 123 4567
ouroffice@aware.com

 

KMF

Why Don’t Developers Write More Tests?

I regularly speak at conferences about testing microservices, and one of the first questions I ask attendees is whether they write tests or not. The room is usually split 50-50 between developers who write tests for their code and those who do not. This disparity gets more pronounced when I give guest lectures at coding bootcamps where I’ve found that fewer than 1 in 10 grads actually know how to write a unit test.

My anecdotal observations have been backed up by surveys as well. Diffblue found 42% of developers skip writing tests and Stack Overflow found 37% of developers don’t write tests for their code at work.

In order to understand why developers aren’t writing tests a little better, I decided to bring up the question to several friends who run software teams. In this piece, I’ve collected some of their observations (mixed with my own) about why developers don’t write tests as often as you might think they should. Some of their answers surprised me, especially as we talked about the limitations of testing today.

Finally, I asked each of them to give me some tips for engineering leaders and developers who might be new to automated testing. If you’re among the roughly 40% of developers skipping tests today, I hope their advice encourages you to get started.

Objections to Testing

Broadly speaking, automated tests tend to improve software reliability, quality, and maintainability.

“If you have tests in place for a feature, then you will know if some future change breaks something,” Adam Gordon Bell of Earthly told me. He added that tests serve as a dynamic form of documentation: “Many times it’s easier to understand what something does by reading tests than by reading the actual implementation.”

That said, writing tests takes time and many developers do not (or cannot) make the time to write them. As the codebase grows and test coverage continues to slip, this problem gets more pronounced.

“Management frequently pushes a large set of functionality and testing always slips down the priority list…once you have a large enough codebase, you can spend an infinite amount of time writing tests, so it can be daunting and hard to know where to start.” – Ken Ahrens, CEO at Speedscale

If deadlines are tight or the team leaders aren’t especially committed to testing, it is often one of the first things software developers are forced to skip.

On the other hand, some developers just don’t think tests are worth their time. “They might think, ‘this is a very small feature, anyone can create a test for this, my time should be utilized in something more important.’” Mudit Singh of LambdaTest told me.

I’ve seen this attitude of tests being “beneath” developers in enterprise settings where dedicated QA teams might be responsible for the bulk of tests, but it can happen anywhere. I managed a senior developer at a startup once who encouraged me to hire junior developers just to write tests for him.

Testing Tradeoffs and Limitations

So, you might think that the answer is simple. Give developers more time to write tests and make it part of their job, right?

In truth, there are some legitimate limitations to automated tests. Like many complicated matters in software development, the choice to test or not is about understanding the tradeoffs.

“Writing automated tests can provide confidence that certain parts of your application work as expected,” Aidan Cunniff, the CEO of Optic told me, “but the tradeoff is that you’ve invested a lot of time ‘stabilizing’ and making ‘reliable’ that part of your system.”

I’ve seen this in my experience at startups as well. I once spent three weeks building a new feature, writing tests, and resolving code reviews only to be told that the business team had changed its mind and the feature was going to be removed in the next sprint.

While tests might have made my new feature better and more maintainable, they were technically a waste of time for the business because the feature wasn’t really what we needed. We failed to invest enough time understanding the problem and making a plan before we started writing code.

“Imagine a bunch of construction guys and the architect meet in an empty lot with the customer and a big stack of lumber. Then erecting a house in a spontaneous fashion. When the customer looks dubiously at the finished house and complains that the roof doesn’t look very secure the contractor replies ‘Don’t worry, we’ll just wait until it rains and then patch where it leaks.’…No other profession builds products of uncontrolled quality then relies on testing (and defect repair) to improve the product quality.” – Software Testing Myths

Finally, some forms of testing are particularly difficult to implement because they require your code to be written in a specific way. This is a common complaint about unit testing.

On one hand, unit tests force developers to structure their code in a way that is “testable,” but on the other hand, these unit tests rarely tell you if the final application is delivering value to users.

“In most businesses, the only tests that have business value are those that are derived from business requirements. Most unit tests are derived from programmers’ fantasies about how the function should work…Those have no provable value.” – Why Most Unit Testing is Waste, James O. Coplien

If you’re working in a legacy codebase that had no unit test coverage before you started, it’s almost impossible to add them retroactively. So, most developers turn to integration or end-to-end tests.

These functional tests can be helpful, but they are also problematic. Any significant application will have dozens of features and logical branches, so it becomes nearly impossible to keep up with all the intended behavior. As J. B. Rainsberger points out in his essay, Integrated Tests Are A Scam, a mid-sized web application with 20 pages might need 10,000 to 1,000,000 tests just to cover all the user stories.

So Why Even Try?

“I think that unit testing and specifically test-driven development was oversold by its proponents as a cure for all problems…But testing, when done well is very valuable. Write tests for the future you, who will be trying to understand what this method does in the future. Give yourself the confidence to make the changes you need to make.” – Adam Gordon Bell, Earthly

While testing isn’t a panacea, it is legitimately useful when applied appropriately to the software at hand. In almost every case, testing is a net positive for developers even if it has limitations. The important thing for development teams to do is to be intentional about how and what they test.

“Being deliberate about where you invest your testing efforts is the best way to balance your investment with the value it provides,” Aidan Cunniffe told me. It might be reasonable to skip tests on your first alpha release of a new feature, but “when that feature becomes the backbone of 3 other features, it’s time to start testing.”

Personally, I take the stance that a blended approach is best. Unit tests are useful for covering lots of minute cases quickly, integration tests ensure that pieces interact as expected, and end-to-end tests provide a final check that the user interface is working.

There are also new varieties of tests emerging that seek to mitigate some of the shortcomings of the layered testing approach many of us take. For example, I investigated a number of low-code testing tools last year, and even more is on the horizon. Sushil Kumar, CEO of RelicX pointed out that “Automatic generation of test scripts using AI/ML-based testing can go a long way towards reducing the developer burden.”

Getting Started

If you’re this far into the debate and you’re simply not testing because you’re not sure where to start, let’s talk about where you can get started.

The easiest place to start is typically unit tests. “When you are just getting into testing, figure out what unit test framework your team uses and include a unit test case for your first code check-in,” Ken Ahrens of Speedscale told me. Going on to explain that starting small but making tests a habit is the key to sticking with it.

Next, you need to get buy-in from the rest of your team and the leadership. Developers need to be given time to write tests with the understanding that this investment will pay off in the long run.

“Either everyone on the team is writing tests or nobody is, it really is a cultural practice, a technical standoff. Nobody wants to be the only person who does it.” – Aidan Cunniffe, Optic

One way to prove how valuable tests can be is to use them to prevent regressions. “If something is not working,” Adam Gordon Bell told me, “write a test for the correct functionally before you fix it.” This will make future regressions less likely and give your team confidence when updating that part of the code in the future.

Tests have limitations and they’re not a substitute for great system design, but tests also have their place in software development. Giving engineers time to test and imparting the value of tests onto your team is an important role in engineering leadership, and it’s only getting more critical as software gets more complex.

If you’re still not testing, I’d love to hear why. Find me on Twitter and let’s pick up the conversation.


Credit: Source link

Previous Next
Close
Test Caption
Test Description goes like this