Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Implementing Unit Testing: Goals

DZone's Guide to

Implementing Unit Testing: Goals

This series talks about creating a sound unit testing strategy; the first thing to think about it your goals. Read on for some pointers.

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

In this series, I’m going to discuss the strategy of how to roll out a unit testing implementation in an organization. As we all know, most unit testing initiatives start by developers, and if they are lucky, it gets picked up by their team, and maybe, in a viral fashion, go on to other teams.

This is all very dependent on how well the process goes, how people respond, and more importantly, how much management gets behind it.

But when it does happen, it is still fallible. So how can we support the process, in such a way that teams adopt it, and continue doing it?

That’s where this series starts. We’ll go through the different aspects of implementing the process. And we start with the end in mind.

GOOOOOOOAAAAAALLLLLLL!

Okay, maybe not that kind.

We want to know what to aim for, so we can adjust accordingly. As with any new process, the chances that everything goes according to plan is quite low, so keeping in mind what we want to achieve is important.

Sustainable, Continuous Effort of Unit Testing

Obviously, that’s the major one. We want writing tests to become an integral part of development. And it’s not just about writing – we want to include the unit testing strategy as part of development. The sustainable part means that it’s not just part of writing software, it also doesn’t require extra nagging.

It’s just part of the job.

Tests Are Effective

Yeah, we kind of miss that sometimes. Good, effective tests don’t just write themselves. Unfortunately, the tests we write first are pretty crappy, and those live the longest. We want that after testing becomes a way of life, we write effective tests, and get rid of the bad ones.

Quick On-Boarding of New People on the Team

Remember, the goal comes after the implementation plan, so we want this goal to be attainable after the initial roll-out. When new people join the team, without knowledge of basic testing skills and particular team knowledge, we want them to get onboard with the least hassle possible. This doesn’t just happen by itself, and we’ll need to invest time and resources to make that happen.

Easy On-Boarding for a New Team or Group

If there are only a handful of developers, that’s not a priority. But if we want our 500 team organization moving towards developing tests, that’s an issue we should address. Note, that here the focus is on “easy,” not “quick.” We cannot expedite a new process implementation, it just takes time. We do want to be prepared, with examples, coaches, etc., to support a new team starting out the unit testing way.

That’s a nice set of worthy goals. Of course, you can add yours if they are as worthy.

Next time we’ll discuss how we know we’re there and what leading indicators we need to track.

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

Topics:
devops ,testing ,unit testing ,software development

Published at DZone with permission of Gil Zilberfeld, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}