How to convince programmers in my team to do unit testing

šŸ—„ļø Archive
1

Yo.

So I generally consider my team to have pretty ok attitudes when it comes to quality, but a couple of months ago I found out while doing an audit (with the team) of all our automated tests that we have very little unit test coverage. Some parts of the system have none at all, even the more modern things weā€™ve built.

Iā€™ve been getting soft resistance to my influencing, arguments like it adds time and ā€œunit tests are great, but I donā€™t think it would add value to this particular part of the systemā€. Since Iā€™m not a programmer (I dabble) and have not written unit tests before, itā€™s hard for me to come up with non-general arguments against this. Everyone is aware of the advantages of unit testing, but it feels like no one really believes it in their hearts. Weā€™ve talked about how they are small and quick to run, they identify problems quickly/early/while devving. They make refactoring code safer, and provide living documentation of what behaviour is expectedā€¦ Everyone is aware of all these things, and when we talk no one is outspokenly against unit testing - just every single time they have an opportunity to write some, there is an excuse not to. xD idk if this could be a confidence issue where no one is sure how to write good unit tests, although I donā€™t have any guidance to give on this matter.

Do you have any good resources for devs that I can share that gives a devā€™s perspective on why unit tests are great, stories from developers who started using them or just particular ways of framing the discussion that youā€™ve found effective? Or any resources on how to write effective unit tests, examples etc.

Thanks in advance

2 Likes
2

Doesnā€™t it look like a good direction?

image

1 Like
3

I wish I could help, but Iā€™m in a somewhat similar situation. I did work with a team, once upon a time, where the unit-code evangelist was so persistent, that the team eventually said, ā€œFINE! But just one sprint!ā€ The short of that story is, it turned into, ā€œThis is SO amazing that we donā€™t want to stop!ā€ in just that one sprint. They used more time to design, but significantly less time for the code in just that one sprint, so the time to make the code balanced out. Once they got better at creating the unit tests, the time-to-test dropped like the proverbial rock.

The best part for me was, after we started testing, we had to get much more creative to find the really interesting issues. So rather than testing, ā€œDoes it meet our specs?ā€ We could test for, ā€œWhat havenā€™t we thought of yet?ā€ It was a very interesting time.

My newest team usually off-shores our code, and focusses on design and testing. The code we get from ā€œoff shoreā€ almost never has any unit tests. We are working on improving this. The most significant change for us has been that we pulled in a new team member who is a HUGE fan of unit testing, but as testing, which isnā€™t really the point, but stillā€¦ a coalition has been started. Using more people has turned the other team members opinions, and (hopefully) soon we will require that our coders provide unit tests. If they are good remains to be seen. But at least they will be there.

2 Likes
4

Since I have been wrestling with a similar question and was curious about resources, I tested my google-fu on this question. Yes, I found the usual suspects, the invariable copy-and-pasted lists which say ā€œThis is a benifit, but Iā€™m sure as heck not going to tell you why!ā€ lists. But then I came across this gem.


I still have no idea who stxnext is, but I do like the approach (even if I disagree with their maths). What I like is that if you give a (good) engineer something to measure, then they are (often) likely to want to measure it. At least, thatā€™s the way it looks in my brain. So if you say, ā€œThe success of unit tests can be measured,ā€ that multiplies the chance that someone will want to try it.

2 Likes
5

Hello @undevelopedbruce!

I agree with you and have experienced the benefit of unit testing. I have found that some type of products under construction benefit more from unit tests than others. Various versions of my experiences here appear in other posts.
I was a Test Lead on an enterprise project where the project team needed to build Application Programming Interfaces (APIs). In my opinion, APIs are a natural for lots of unit tests because they are small, isolated, and very testable. For this project, I wrote into my Test Strategy document that unit tests were our primary method of testing.
I also met with two people on the project. I met with the Development Lead and she agreed with me on the approach. Having this support, I believe, is key. I also met with the Project Manager. This is where you may need some faith.
In my opinion, all of the behavior of an API can be evaluated in unit tests. If this is true, then there should be little or no time required from testers. However, I encourage testers and developers to collaborate on test scenarios. I believe that all scenarios can be explored in unit tests. If this is true, then testers should require little or no time to evaluate an API. This is what I present to the project manager: we spend time in creating and developing unit tests and little or no time in other tests. That is, the API is ready for deployment (did I mention faith?). No large test event is required. The Project Manager agreed with me.
Over 21 iterations (two weeks per iteration), we logged 22 defects. The APIs deployed into production with one or two low severity defects.

Presently, Iā€™m in a testing advisory role. While the products are not APIs exactly, they are similar enough that unit tests can evaluate all behavior. I had worked with the Development Lead and Architect during a Proof of Concept and pitched the idea of unit tests; they were in agreement. When I met with the Test Lead, I recommended that the Test Strategy state the primary method of evaluation is unit tests.
While we have just started development, I have found that some developers are unfamiliar with creating a good unit test. Some were mocking so much that it seemed no actual code was exercises. I believe unit test reviews will assist them in creating better unit tests. As before, the testers are collaborating with developers on scenarios.

Joe

2 Likes
6

I think there are prerequisite skills to being able to do this, which I donā€™t have. But the idea is sound, youā€™re right I should experience something if I wanna get other people to do it. I will talk to one of the devs and invite them to pair with me on their next story so we can work out how to write good unit tests together. Then pair with another person, then another and maybe we will discover the boons properly together. I think that would be more productive than me trying to muddle through on my own, or trying to talk other people into muddling through on their own. :+1:

1 Like
7

Uwoh there is loads of great advice here, I am taking it all in for sure. It is very much appreciated

I am going to:

  1. pair with developers on stories so we can work out how to write unit tests together and take the pain point away from individual team members
  2. talk to our team lead about his views on unit tests to see if I can get support from him to encourage the rest of the team
  3. find unit test advocates within the company and support them in their advocacy
  4. share the article Brian suggested with the team, hopefully to start positive discussions on the subject

Iā€™m glad to hear that APIs are some of the more coverable things because I was having real trouble being told that we donā€™t need coverage in our APIs or Cloud Functions bc of various arguments (theyā€™re so simple/straightforward they donā€™t need them, stuff like that).

I just donā€™t have the experience (or confidence I guess?) to back myself up when I have a few people telling me something thatā€™s contradictory to my belief/common sense and I have no one else on side xD Especially since Unit tests are traditionally the thing that programmers do as they work, so itā€™s really not my realm of expertise haha. I will be more steadfast and I will come back here and read your replies again if I get discouraged again!

Thanks everyone!! <3

1 Like
8

Hello @undevelopedbruce!

I moved from Development to Testing a bunch of years ago. I was surprised to discover how social testing is and had to learn better speaking skills. I believe you can do the same!

A short list of why I advocate for unit testing:

  • rapid feedback
  • leading indicator of quality
  • collaborative
  • no testing event
  • support CI/CD

Joe

2 Likes
9

Iā€™ve read a lot of great suggestions and tips already but I still would like to add my own experience.

You already mentioned all the benefits unit testing will give you (small, fast, early, stable, etc), but as you also already mentioned, itā€™s like they donā€™t really believe it. In my experience this is usually the case when the team doesnā€™t own quality, but you, the tester does. When things go wrong everybody is looking at you to come up with an explanation. Now, the team is perfectly fine with having a gatekeeper in the form of a tester, especially if it saves them from having to do stuff they donā€™t like, like unit testing.

Whenever I join a new team I always set some expectations, one of which is that I think that quality is a team responsibility and that everybody should do their part in getting quality as high as possible. For developers this can be translated to: write some unit tests. Now, you can hammer them over and over and over again about the benefits and why they should do it, but as long as they donā€™t feel the consequences of not doing it, they will just carry on as they were. A lot of developers donā€™t really care about the quality of what they build because there is a safety net in place: the tester. Iā€™ve noticed that talking about consequences is way more effective than hammering the benefits. It might sound a bit harsh, but bear with me.

Of every developer I expect them to write code and solutions in such a way that they are confident enough to release it to production right away, without someone intervening or checking or testing. If they donā€™t feel confident enough to do this, then they still need to do some work. Writing unit tests is an excellent way for developers to increase confidence. As is simplifying the solution, or trying to get some requirements more clear. Of course, some will just say yes and release anyway and things will fail. Then itā€™s very important that you keep it blameless, but also indicate that this could be prevented. The question to ask at that stage is: what is the earliest stage at which we could have caught this? Most of the time the answer will be somewhere around unit testing. But most importantly, indicate that you are not going to do anything when certain entry criteria havenā€™t been met.

Iā€™m not saying you should remove the safety net entirely, but I think itā€™s perfectly OK to set some conditions on when somebody can make use of some of your precious (testing) time. If the developer isnā€™t sure whether or not a feature is working, how are you suppose to say something about it? Most tester are too modest. It takes courage to stand-up and flat out refuse to do certain things. We care so much about the product that we feel a personal obligation to do anything to make sure that something good is released, sometimes as the only one on the team. Itā€™s very difficult to not feel a little sting of pride whenever a bug makes it to production, but the whole team should feel that sting, not just you.

TLDR (the harsh version): if you donā€™t write unit tests, Iā€™m not gonna bother with testing as well.

4 Likes
10

I feel your pain. The long and the short of it is, while there are good resources out there that can help you build a great argument for why unit testing is needed across an application as a whole, if you donā€™t have buy in from management at any level, itā€™s not going to get done.

Iā€™ve worked with some programmers who are amazing at what they do, but were offended when I found bugs in their code. Unit testing their piece of the application before it was merged was good enough. For others, the argument was that the product has been around for years and all the major bugs have been found. In the end, management, starting with the Program Lead, had to dictate that unit testing is mandatory before it was done regularly.

One of the most effective means Iā€™ve come across that shows a developer just how important unit testing is, is peer reviewing their merged code (before it is built to the test region). When I worked on a team that did this, we didnā€™t test every iteration of the code, instead we tested that the main points of the user story (yes, it was an Agile team) were met. As we progressed through the Sprints, the developerā€™s coding improved as well. This also led to creating better on-boarding practices for new developers. This practice was started by the development lead because of the initial issues found in the code by testing.

I hope this helps.

2 Likes
11

Iā€™ve been in this position many times over my career. Evangelizing did not work for me. I was greatly helped by the patterns in Linda Rising and Mary Lynn Mannā€™s Fearless Change books. Also, itā€™s important to look and see what management is doing and what the programmers get rewarded for. If managers are driving them to deliver features by deadlines and donā€™t give them time to learn - and it takes a LOT of time, months and months, to even get traction on automating unit tests - they arenā€™t going to try it. It DOES add more time to their job, and it takes a long time for them to build up a library of reusable parts and expertise to start seeing the benefit of saved effort. I wish I could attach a picture here.

We humans do not really get influenced by facts, but, you might check out some of the case studies Jez Humble has on the benefits of automation, like for HP FutureSmart (should be able to google that).

4 Likes
12

I think you hit the nail on the head here. I consider the team to be fairly quality-minded, especially compared to last year, so this reasoning didnā€™t hit me but you are so right. Everyone on the team gets involved with testing activities, and the developers spoke about how empowered they felt to make decisions around quality in a recent feedback session - but I think it just hasnā€™t occurred to them that unit testing is part of that. Thanks for the insight, and I will make sure itā€™s clear to the team that unit testing is part of our strategy for quality, and I will ask our team lead if we can have a time slot for mobbing on what we think good unit testing looks like, give people a chance to air their concerns.

1 Like
13

Thatā€™s a well measured response, thank you. Iā€™m not sure I can motivate the team to write unit tests for months and months before seeing the goods, so I will go up the chain to the CTO to see if we can work together on it if he has time. I think heā€™s the only person with reach and clout enough to make it happen. xD

And thanks for the mention of Jez Humble, I shall do the researchy searchy!

14

To me, it gives the devs more of a safety net when they refactor or make other improvements.

2 Likes
15

Hi,
ā€˜I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidenceā€™

Developers have to find the need of unit testing for themselves.
Iā€™ve met hardcore developers(30+ years coding), single man product builder, that were writing integration tests only.
Iā€™ve met overdoing developers - that wrote so much unit testing code that they needed 25-30% of the whole development time to maintain them.
Iā€™ve met developers that didnā€™t want to do it, no matter the amount of training and convincing(~2 years). And when they did them, they just wrote crappy unit tests that were asserting something like true=true, as some senior developers reviewing their code said.
As a tester you could pinpoint to conscious developers constantly the mistakes they make. And them to acknowledge that and act on something. It can be unit testing or something else.

16

Refuse to test anything that could be covered by unit testsā€¦

1 Like
17

Get them to refactor the existing code without existing Unit tests, then get them to refactor existing code with existing Unit tests.

Ask which they preferred doing, if they say the latter they are lying.

Also start advocating TDD, then youā€™ll get your Unit tests as part of the development.

But finally you need everyone on board, not just the developers, you need the management onside as well as they need to understand that code may be handed over later (oooo they donā€™t like that) but it will be of a higher quality and more maintainable in the long term (ahhhh they do like that).

Developers will be constantly getting hassled to produce quickly, if the people doing the harassing can understand that this leads to wasted time at different points later in the development processes then they will support your efforts.

18

I see little point in writing unit tests after the fact. Am reticent to admit this, but right now on one small project, the build script does not have the unit tests tacked on, its a separate target. So builds still succeed even if the unit tests donā€™t. Which kinda makes playing policeman on that program is not going anyplace. This is the starting point for many of us I guess.

I want to go with the pairing thing, but have not done it very often. Sit with the developer and helping them to write a feature is a way to understand the feature better, you do have to play duck. And be able to read code. And the developer has to be happy to work in TDD mode. You have to have memorized the requirements, so that the dev can use you to explore the requirements. It also means you have to have finished all your test design/planning work by the time coding starts. The pain is when the feature is very UI intensive, unit testing becomes non trivial if there is no mocking in place already. So unless you are prepared to help, you have no currency.

1 Like