How would you convince your company to implement unit tests?

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!! ☺️☺️☺️

Did you find this post useful? Show some love!

For us, it helped to implement the tools that measure code coverage and give grades, like Code Climate. Somehow it's a bit easier listening to robots.

Code coverage is a flawed measurement, but it can help in a lot of ways

Thanks for your comment Ben, I didn't know Code Climate! It looks quite interesting.

I would say try first to push for functional tests before if it's a web shop.
It always depends on the types of the projects and the allocated budgets.

Try being practical, like, hey guys, remember the time when the 'register' part of the website didn't work because of push X? Here's a way we can easily test for that. Having clear examples is always a good first step.

Who is "them" ?

If it's your developer colleagues you shouldn't have too much trouble convincing them of the benefits, writing tests has more or less been industry standard for around 10 years now.

In short

  • Less bugs
  • Much safer refactoring so easier to change code
  • So faster development in the long run

If it's management, I would contest that you do not work at a super cool company. Do you ask permission to write classes? if statements? In 2018 writing tests is just as much as being a developer as refactoring is.

As a professional you are the expert being paid to make the right decisions as to how to make a maintainable system, not management.

Thanks Chris for your comment! Maybe I was wrong saying that was a super cool company in the example but that was to focus in the unit test topic (pros and possible cons) and not in another business issue like supervisors don't listen to you or something like that. I really liked you thought in both tech and management terms.

Ben Halpern DEV.TO FOUNDER

Hey there, we see you aren't signed in. (Yes you, the reader. This is a fake comment.)

Please consider creating an account on dev.to. It literally takes a few seconds and we'd appreciate the support so much. ❤️

Plus, no fake comments when you're signed in. 🙃

Do they have functional / integration tests or no tests at all? Unit tests might not be worth it in some scenarios, especially if you have to deal with a legacy app with no tests.

I would bring up the rate of bugs and regressions and start from there. In the meantime you can start testing your code and maybe start adding those few tests in the CI pipeline.

Thanks for the comment! I think the rate of bugs is a very good point.

Convincing the company could be one of two things and I’ll just address them both.

Convincing leadership that you need tests of any kind is simple: “we need to do a little bit more work now in order to ensure that when someone new comes along and breaks things, they know immediately, without asking another developer, that something is wrong.”

Convincing other developers is also fairly simple: “we write unit tests so that when we break stuff we can get instant feedback on what we broke. We might even have planned for that to break because we’re changing a contract, then we see it break and have confirmation of that.”

I used unit testing in my own code and implemented it in the code base as a lunch time project. Being able to show defect reports in our own products dropping really helped me. That alone didn't stop every one's eye's rolling when I talked unit testing but it helped. Then articles. What I told them was that we start today with new code. and with anything that needs revision. We aren't going back to "waste time" unit test old code

Good luck!

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.

See what you're saying but it was choice between my way or nothing.
The way I see it at least I can say I tried. There have been places where I've been the only one to code tests. I say try and hope for the best

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.

It’s a basic truth that (a) adding features and (b) being relatively bug free, are equally essential to most businesses that want to attract and retain customers. Unit tests allow you to focus on the former, while having confidence that you’re doing fine with regard to the latter.

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 actually read an article about this exact subject:
typemock.com/convincing-management...
Please let me know if you liked it :)

Yes, the article was quite interesting! Thank you for sharing it :)

No problem, I'm glad you liked it! :)

I highly recommend reading Li Haoyi's blog post on how to change a company from a software developer's perspective.

Correct me if I'm wrong, but it sounds like you're in a larger company at the moment. This might be why it is more difficult to drive change - don't let that discourage you though.

I think that in your case, driving change will be more about increased quality than increased efficiency. Think of business critical code, and find a way to convince management that continuously testing the code is valuable. For me, the most critical code has been security sensitive code. Start small, and once others are on the bandwagon, you can push for even more testing.

When I was in that situation, I shared a lot of articles about the benefits of writing unit testing.

There's always watching out for people breaking existing code, jumping on them and yelling "I told you so you should have written tests".

At some point the nerves crack.

Simply by doing it! Walk the talk, practice what you preach, seeing is believing.

Classic DEV Post from May 21

Quick Advice For Junior Devs

Some thoughts for junior devs.

READ POST
Follow @mattsparks to see more of their posts in your feed.
dev.to is now open source!
View Announcement Post View GitHub Repo
Manu Lopez
Your friendly neighborhood Uncaught Exception.
Trending on dev.to
What part of your first dev job were you least prepared for?
#discuss #career
Testing vue-apollo Components with Jest
#vue #graphql #testing
Fail Mail #1: Failing at Git Publicly
#webdev #javascript #career #productivity
Sprint Planning as Self Care
#productivity #career #agile
Follow Me, Rubyists, Because...
#testing #ruby #github #debugging
How to take breaks while coding
#productivity #learning #career
Who Tests Code
#testing #qa
Code Talk - August 2018
#webdev #discuss #learning #career