Using Test-Driven Development to Achieve Agency Goals

Achieving project success is hard. We’ve all heard or been part of an initiative that seemed primed for it. A talented team was assembled. Senior leadership was brought in. Every resource was made available. Yet, things didn’t click. Months after starting, the pieces didn’t fit, and the team was spinning its wheels.

If you talk to the members of this team, you might uncover a common hurdle for projects: While everybody was excited about the grand vision and potential value, nobody was sure what the specific goals were. The team hadn’t talked about these goals, each member moved forward with their own assumptions, and, because of that, nobody realized there was a problem.

How do you and your colleagues know you’ve done what you set out to do? To answer this question, the Granicus Engineering Team constantly defines and reviews goals thanks to a steadfast reliance on one of our favorite engineering practices: Test-Driven Development.

Test-Driven Development Requires First Defining Your Goal

Whether you’re starting a multi-year project or an afternoon task, defining your goals at the beginning provides you and your team with direction. Much like a family going on vacation, you need to decide where you’re heading before going anywhere.

For the Granicus Engineering Team, Test-Driven Development helps us to keep goal definition at the front of our process. In fact, goal definition is step 1 of the Test-Driven Development loop:

1. Write a test representing what you want to achieve
2. Evaluate the test; it should fail
3. Create or change the software that the test is testing
4. Evaluate the test again:
   • If it fails, go to step 3
   • If it passes, go to step 1

Writing a test first pushes us to define a goal. In doing so, we often uncover new ideas and differing assumptions among our teams. We might realize that our initial goal was too big or that it conflicts with other goals.

Consider a discussion about that family vacation: You say that you want to go to France. Your kids say they want to go to Florida. Your spouse reminds you that you all want to move to a new house. So together you all decide that a staycation sounds like a lot of fun.

You might be asking: Why evaluate the new test if you know it’s going to fail? Step 2 again forces us to examine assumptions and scope. If I write a test that doesn’t fail, I might have some incorrect assumptions about our existing software. Maybe our software already does what we want, or, perhaps, some miscommunication among our team led me to leave out an important detail. For step 2, a passing test can be a warning that we need to regroup, examine, and discuss to ensure we all have the same goal.

Revisit Your Goals Often

Defined goals don’t just give you direction. Once you’ve achieved your grand vision, they become a historical record of what you have done and want to preserve, even as you move forward with your next project.

At Granicus, the tests we create during Test Driven Development act as our historical record. Our tests become a principle internal reference for how our software should work. For example, based on our tests, a future team adding features to govDelivery’s Advanced Bulletin Editor will know that it must continue to support linked files and display footers. By looking at these and many other tests, any team member can quickly learn what a piece of our software needs to do and how to use it.

But goals are more than just static reference. Historical goals can continue to be measured against. To really maximize the value of this record, goals should be evaluated as changes occur, so you and your colleagues can know right away when a new activity is in conflict with a longstanding goal.

Over the years, the Granicus Engineering Team has written a lot of tests, and we’ve invested in tools and processes to automatically evaluate these tests. As a result, many of our tests can be evaluated very quickly and very cheaply.

And we evaluate. A lot.

We evaluate tests while writing code. We evaluate tests when we share our changes with our colleagues. We evaluate tests when we deploy software in our testing environments. We evaluate tests when we release software for the public and our customers.

At every step in our development process where some change can occur, we run our tests to ensure we are continuing to meet our goals. In our ever-changing world of new technology and improved features, this frequent testing gives us confidence that we constantly provide high-quality software that meets your needs.

Putting It All Together

Test-driven development can benefit nearly any agency, organization, or team just by following these steps: Define your goals as a group. Write them down and refer to them often. Check your work against those goals – while you’re pushing towards them and when you’ve moved on to new challenges. Whether you’re writing software or connecting the public with critical services, clear goals drive success.

If you think your organization could benefit from solutions Granicus tests over and over again, get in touch with us today.