Scenario
Suppose you are working in a super cool company, your coworkers are great and your job is fulfilling, but your company doesn't implement unit testing as it doesn't see any benefit from a business point of view.
What would you do?
As the title asks, how would you convince your company unit tests are beneficial? Would you try to convince from a technical point of view or a business point of view?
It would be great to read your comment!! ☺️☺️☺️
Latest comments (29)
I wonder why people don't implement unit tests?
Our industry made awesome progress when deciding to start writing tests as the standard, but still need to add the DESIGN!
Which for me implies thinking/writing the software as interconnected pieces which play different roles.
At that point, writing isolated tests for those
Unitsshould be the norm.Sorry I didn't answer your question.
I would start writing my own unit test.
People will start making comments against them in your PRs
And there you can point them to the literature, or talks around this topic.
A good tip for writing easily isolated tests is:
1- Search in the code for classes which have no dependencies and write a spec for it.
2- If you see a repeated behavior in two different classes Apply the
Extract classrefactor and create an isolated test for this new class.Tests help ensure confidence in the quality of the initial version of the code as well as when it is changed in the future. Growth is a form of change. Therefore if your business is growing it will necessarily change.
Here's an example: Go and take 5 modules from your codebase that don't have tests. Write unit tests for them. I would bet a good sum of money on two outcomes: For one, you will found at least one bug. Whether it's an edge case that was previously unknown such as a missing null check or a max integer overflow or incorrect business logic: you will find something incorrect.
Two, you will find ways to improve the module's API. In an organization with several developers strong API contracts are incredibly valuable. Tests help you to think like other developers and provide an example of how you intend for the module to be used. This allows developers to be confident in each others code and unblock themselves without interrupting one another.
Edit: Not that I want to write novel here but another point... When developers start writing unit tests there is initial learning curve. Unit testing is a different way of thinking and uses different APIs. This is especially true for devs that no experience with tests. You have to message clearly to management that starting the practice has that initial cost. Additionally, be sure to look around and try multiple frameworks to be sure you are using the most efficient tools for the job. Pair programming is especially great for teaching how to write unit tests. Good luck!
Unit tests might be hard to sell. Even at my current company, we have very little unit tests. But we have lot of tests, mostly functional and integration tests that being automated. Tests that every developer can run with just a single command
make tests, or hook up into CI tools that automatically run on open PR or certain commits. This is much easier to sell. Who don't want just sitting around while computer do the work, instead of endless clicking and typing the same thing over and over again.It amazed us when people say we don't do testing. What? You didn't test your code. So you just wrote it and ship it, and it just work? That's heaven. What they actually mean is that they don't automate their tests. Truth is, everyone are doing tests, the moment they write single line of code. This I think the crucial understanding we must put first. When we talk about writing tests, people think that it totally new things, so it must be hard and probably not worth doing it. But once we make them realized that it's no different than what they already doing (just being more efficient), they will start seeing the value of doing it.
First try and see it their way. Understand from the business perspective why these decisions are being made. (You might have to dig and ask a lot of hard questions.)
Hard questions uncover hidden truths. Not everyone is comfortable with this, especially if you are changing the status quo. You may open yourself up to attack in an unhealthy culture. Do not do this alone.
Identify places where testing would have saved time (money). Catalog these scenarios as they play out so you can present them later.
Find allies within your company and share what you are learning. Do they experience the same pain points as you? How can you work together to educate and change the culture?
When your group is ready, present your case to the nessesary stake holders. With consensus from allies, draw reasonable lines in the sand together.
Define your process and your definition of done to include the quality measures that add real value to the business.
Measure. Define. Align. Push back together.
Once you've gain acceptance at scale, implement controls to stop quality from slipping in the form of tools and process. Enforce your process with tools whenever possible. Coverage and reviews, realtime quality measures, etc.
If it wasn't worth it, it wouldn't be so difficult.
Go get it.
Is funny because I'm right in the middle of this exact dilemma. I was handed a large project and part of that is a major refactor of one of our mission critical components. So I am building my integration to work independently and then when it comes to making the full switch I'm going to fully build out all tests. I have a feeling when the transition goes smoothly, without breaking anything, my lead will see the value.
Thanks for the comment Sam and I really hope everything is going well with these tests. An interesting approach could be to try to "sell" unit testing from a business point of view (pretty simple example: spend less time fixing bugs and you will reduce costs in that project). Keep us up to date with the project refactor and testing!
A former agile coach of ours told a story from back in time he was a CTO. Top management didn't want to invest in (unit)testing, they didn't support the idea to say the least.
One evening the CTO told the big boss that he could save him X amount of money very simply. Words went on, this future coach showed the CEO how to implement unit tests and how they help to prevent bugs.
The next days, communication arrived from the top that everyone should write unit tests for the new code.
So try to sell it with what the business like. They like more revenue and less money spent.
Thanks for the comment Sandor! I think your comment could be really helpful for many developers as it shows that companies sometimes only listen to business reasons and not too technical reasons. Sometimes we lack in the way we communicate with non-technical people and this could be a good example.
Simply by doing it! Walk the talk, practice what you preach, seeing is believing.
Usually production failures do a good job of justifying testing. But then knee-jerk reactions cause the pendulum to swing too far (like mentioned in Dan's post that Ben mentioned).
I mainly implement unit tests on a subset of code. Tests are required for the main business logic. We use Dependency Rejection so that we don't have to mock IO intermixed with business logic, so it is not hard to do. I've also had to unit test finicky libraries that can fail subtly based on settings (i.e. reflection-based serialization). But I don't test much IO. We use code paths which are few and well-worn for IO. If there is a runtime IO error, it is because of outage. Then it becomes an admin (or cloud infrastructure / resilience) problem anyway.
That is in our later projects. Our legacy code is a big mess and we basically don't unit test it (only manual acceptance testing). And deploying it always feels like jumping out of a plane and attempting to put on the parachute as we fall. We have tried writing some unit tests for it, but to even do so requires significant and risky refactoring. Instead we've been carving off chunks and rewriting them to the newer style.
I've never personally witnessed the sort of change you're describing. At the large company where I worked one developer after another tried to explain it to us, even doing lunch trainings. No one caught on. I followed the crowd. A small part of the problem was that we confused unit testing with TDD, which makes it seem much more difficult. A bigger part was that we were ignorant and apparently loved bugs. Each of these developers gave up and moved on after a year or so.
Another developer joined, and really tried hard to sell it. He wrote lots and lots of tests. He did a lot of great work and did it at least three times faster than anyone else around him. That's conservative. At this point I got it. Still ignorant, however, I assumed that me getting it meant that everyone else did too, but it turned out that now only two of us were writing unit tests. Then he gave up and moved on.
Now it was just me. I tried really hard to sell it. Some of the managers, themselves previous developers, didn't even know what unit tests were. I showed them how I could write software that worked with very few bugs and do it faster because I always knew that a unit of code worked before committing it. Then I gave up and moved on.
I'm not saying that it can't be done just because I couldn't do it and a bunch of developers smarter than me couldn't do it (especially because it's just one company.) I just wouldn't beat your head against it too long. Unit tests are a good barometer for the health of other practices. If a team or department won't adopt unit testing then they love bugs and only a manager who gets it and enforces it has a chance of making a difference.
That approach can lead to you being the sole maintainer of tests. I'm in that position now where other devs routinely break existing tests and resolve the failing tests either by deleting them or commenting out.
I think it is pretty easy making the case for automated testing to management but to developers not so much.