On crossing the bridge into unit testing land

Maybe it’s just the people and organizations I meet and work with, but no matter how active they’re trying to implement automation and involve testers therein, there’s one bridge that’s often too far for those that are tasked with test automation, and that’s the bridge to unit testing land. When asking them for the reasons that testers aren’t involved in unit testing, I typically get one (or more, or all) of the following answers:

  • ‘That’s the responsibility of our developers’
  • ‘I don’t know how to write unit tests’
  • ‘I’m already busy with other types of automation and I don’t have time for that’

While these answers might sound perfectly reasonable to some, I think there’s something inherently wrong with all of them. Let’s take a look:

  • With more and more teams becoming multidisciplinary, we can’t simply shift responsibility for any task to a specific subgroup. If ‘we’ (i.e., the testers) keep saying that unit testing is a developer’s responsibility, we’ll never get rid of the silos we’re trying to break down.
  • While you might not know how to actually write unit tests yourself, there’s a lot you CAN do to contribute to their value and effectiveness. Try reviewing them, for example: has the developer of the unit test missed some obvious cases?
  • Not having time to concern yourself with unit testing reminds me of the picture below. Really, if something can be covered with a decent set of unit tests, there really is no need to write integration or even (shudder) end-to-end tests for it.

Are you too busy to pay attention to unit testing?

I’m not a devotee of the test automation pyramid per se, but there IS a lot of truth to the concept that a decent set of unit tests should be the foundation of every solid test automation effort. Unit tests are relatively easy to write (even though it might not look that way to some), they run fast (no need for waiting until web pages are loaded and complete their client-side processing, for example..) and therefore they’re the best way to provide that fast feedback that development teams are looking for those in this age of Continuous Integration / Delivery / Deployment / Testing / Everything / … .

To put it in even bolder terms, as a tester, I think you have the responsibility of familiarizing yourself with the unit testing activities that your development team is undertaking. Offer to review them. Try to understand what they do, what they check and where coverage could be improved. Yes, this might require you to actually talk to your developers! But it’ll be worth it, not just to you, but to the whole team and, in the end, also to your product and your customers. Over time, you might even write some unit tests yourself, though, again, that’s not a necessity for you to provide value in the land of unit testing. Plus, you’ll likely learn some new tricks and skills by doing so, and that’s always a good thing, right?

For those of you looking for another take on this subject, John Ruberto wrote an article called ‘100 percent unit test coverage is not enough‘, which was published on StickyMinds. A highly recommended read.

P.S.: Remember Tesults, the SaaS solution for storing and displaying test results I wrote about a couple of months ago? The people behind Tesults recently let me know they now offer a free forever plan as well. So if you were interested in using their services but could not afford or justify the investment, it might be a good idea to check their new plan out here. And again, I am in no way, shape or form associated with, nor do I have a commercial interest in Tesults as an organization or a product. I still think it’s a great platform, though.

12 thoughts on “On crossing the bridge into unit testing land

  1. From my (developer) perspective I have also seen how this bridge looks from the other side.

    This is a solid read on this controversial topic!

    I agree on all points, with the main takeaway being – programmer-tester collaboration is the key.

    Where I want to add something is about test engineers actually writing unit tests. You are spot on there are other ways to have an impact here. And I think most of the test engineer effort should be spent on these other ways, while actual writing is left to the developers.

    Intent on the Unit test is often seen as validation on some functionality, but perhaps even bigger is how it is validating your code design. And the issue is code design is a programmer activity that is dealing with how your code is structured and implemented.

    Test engineers are not that familiar with design. So if they try to write unit tests they and their team will frequently bump into problems, here are two examples:
    1) writing unit tests for already implemented code that is not designed to be testable
    2) making design decisions for the programmer while writing unit tests before implementation

    But but but! Unit tests also test functionality, right? Why can’t testers write those? I think here is where the biggest impact will be to pass the functional knowledge needed to the developer, so tests will be written with both functional and design needs in mind.

    Just my 2 cents 🙂 Awesome post!

    • Definitely agree on all those points, Kostadin! Thank you SO much for sharing your experiences from a developer perspective, that’s gold!

  2. Great post, I totally agree. I’ve always tried to review unit tests wondering if that was a good idea. Due to a lack of time (and not enough resources in testing vs dev which explains why) it has always been very hard to be efficient.

    At least I was able several times to suggest to add some ideas of areas that could be unit tested, and it’s a great help to know what is unit tested in order to chose what should (and what may not need to) be tested with another way.

    You are right that there should be no silos. Testers can help developers to write good unit tests, and developers can help testers to test better on a higher level.

    Also, it depends on the dev skills of the testers, and on the test skills of the developers. Pairing is probably a good idea for this to improve everyone skills.

  3. Pingback: Java Weekly, Issue 185 | Baeldung

  4. An insightful article . I do sit at the development team performing testing closer or similar to unit testing which I call component testing . Even the team I work is development team and not testing team . Along the way it so happen , management might look at it as a over doing of testing . But I agree we should get involved in unit level testing as testers to uncover more symptoms of system failure at the early stage .

    Also governance is the challenge.

    Cheers, Vijay

    • Thank you for sharing your experience, Vijay. Good to see there are some testers actively involved in contributing to unit testing!

  5. Great Article. I love the idea of getting testing involved in unit tests by starting with reviewing them. It is a great way to help me as a tester know what other automation I might want to add (or what automation I might not add now that I know it is covered in the unit tests). It is also a good way to make the testing and development a team sport!

  6. Pingback: Testing Bits – 7/9/17 – 7/15/17 | Testing Curator Blog

Leave a Reply to Dave Westerveld Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.