Checked example testing

Jan — Sun, 08 Mar 2020 16:10:18 +0000

I've come to realize how much developers hate writing unit tests. I read Software Development is Not About Unit Tests a few months ago, a lot of which has really resonated with me through several re-readings to today. I get it. I've written a lot of unit tests; they can be tedious and often harder to maintain than the code itself. It is seemingly a waste of time and the backlash is somewhat justified. Writing tests sucks...

Recently, however, I have begun challenging my team to think about writing tests differently. I propose that there is much more value in a test describing the behavior of the system rather than testing it. It seems pedantic and I don't expect it to be a huge revelation to anyone, but I think this perspective simplifies the answer to the "what do I test?" question.

The problem with the "I know this works, how can I verify that it does?" mindset is that you're missing an important piece to answering the question: how does it work? I would challenge any of you "code is self-documenting" evangelists to look at any of the crap that your colleagues write or that you wrote three weeks ago and tell me exactly what it does and how it was meant to be implemented. I can't either.

If you've never seen the Agile Testing Quadrants, I encourage you to take a look at the chart. The bottom quadrants (1 and 4) are labeled "Technology Facing" and the top "Business Facing"; that means something. Testing is really about understanding the product you have and the users that use it. If you're able to describe and demonstrate how the product solves the needs of your user, then your "test" was successful. You can scale that same concept up (to end-to-end and user-experience testing, whole product-level and organization-level tests where the users are your customers) or down (to unit and integration tests on smaller slices of your product or it's code where the users are the developers).

In this way, the test becomes less of a "test" and more of a "checked example". I stumbled across this label in Exploration by Example, which is linked in the testing quadrants article above. I thought it accurately summarized the idea.

The checked example method makes the tests serve more as documentation of the code and a document for the shared understanding of the system. I think going beyond that to document every behavior of the system is a little silly, so I tend to stick to functions and workflows that need to be documented and understood in some fashion. For unit tests, that could be because it because they include some business logic or because it has cascading effects throughout the application. For end-to-end tests, tests would be for user-facing functionality that describes how the user uses the product to achieve a result.

You can't really verify that a product works without describing how it does. Chances are that your product is not very complicated, so your tests shouldn't be either; keep it simple and describe how the core functionality of your organization and product work. You can incorporate other techniques (user personas come to mind) to help you do that, but keep the barrier to entry low.

This idea is probably more-or-less encapsulated in Behavior Driven Development, but is how I made testing "click" for me. I didn't include any examples because it's more conceptual than that; it's more of a way to think about writing tests than a method for actually writing them.

Breaking Down User Stories: Vertical Slicing

Jan — Sun, 05 May 2019 04:12:21 +0000

This is a concept my team has been working on implementing in our refinement sessions. Talking through some of the general ideas with my friend, I feel like I was able to conceptualize the problems and solutions pretty well and wanted to expand on the approach here.

Everything I'm talking about here is very heavily influenced by the book User Story Mapping by Jeff Patton. My team has read this book together, focusing on a couple chapters a week and meeting to discuss the ideas and how we think we can work them into our processes. This book and approach have been super valuable, definitely give it a shot!

User stories

Anybody that's heard of or practices Agile will be pretty familiar with the concept of a user story. Simply, a user story describes a software feature from the end-user perspective, hence the name! In a user story, you try to describe who the story is for, what is going to be delivered, and why it matters in the first place. It's all about conveying the value of what's going to be created. A user story has acceptance criteria, which are basically a set of requirements that need to be met in order to consider the story complete.

User stories can be broad, that's okay! They can and should be broken down into workable chunks by the development team when it makes sense.

Splitting user stories, current practice

Developers generally approach problems by thinking about how they should be implemented. Consider a story involving a multi-tiered system; you may have a presentation layer, a business logic or backend layer, a persistence layer, and maybe a couple more! Naturally, this leads to slicing the user story horizontally across these layers: a story for frontend, a story for backend, and a story for the database work.

The major problem with this approach is that dependencies are inherent in the way the stories are constructed and, as a result, it takes a long time for any actual value to be realized. You don't have anything releasable to show customers, stakeholders, or users for potentially several sprints. You can't deliver a half-baked cake.

Additionally, you'll be introducing technical debt in terms of toggles for features that aren't production-ready and workarounds needed for part of the feature to work while others are still being worked on. Estimating the size and deliverability of the story hasn't been made any easier and by working the whole story across each horizontal slice, you haven't allowed for any iteration based on user feedback or left room for reprioritization.

Enter, vertical slices!

First and foremost, we want to quickly add value for the users and stakeholders. We can do this by looking at which independent pieces, implemented end-to-end (vertically) across all of the layers mentioned before, compose the larger user story. Identify the value and risk of each piece and prioritize accordingly.

This approach will let you iterate more quickly as features will reach end users and allow them to provide feedback. Unknowns and dependencies don't block progress on the larger feature as pieces can still be worked on and deployed. Your team will be able to respond better to changes in priorities, making you more agile as a result. But, most importantly, you'll be delivering measurable value to your stakeholders and end-users more quickly.

This is pretty abstract and a huge change in perception! Let's practice with a real-world example.

How to vertically slice a story

I work on a mobile team. Ahead of our previous sprint, we were given a story resembling the following:

As a user, I want to know when updates are available so that I can get the latest features and fixes

The acceptance criteria included:

A banner to be displayed on the home page indicating that a new update was available
Cosmetic changes to the existing update link in the user profile to make it stand out more
Both the banner and existing link should navigate to a release notes screen showing the latest changes and links to download the updates

This story isn't terribly large, but couldn't be delivered in a sprint considering there were other items we wanted to work on. It did turn out to be pretty good practice for slicing stories vertically, though!

As a team, we identified that we could add value quickly without delivering the whole story. Taking into account the current state of the app, where the existing update link leads directly to the download, we decided the update banner added the most value to the user. By making the new banner behave the same as the current link, the banner and release notes screen are independent, and can be separate stories. Likewise, the change to the current link adds value independently, and therefore becomes a separate story. This "big" story just became a three small ones that we can prioritize separately!

Admittedly, we did get carried away. We created a fourth story, originally, for updating the navigation from the banner and link to the new release notes screen. Navigation itself wasn't really independent of the release notes screen, so it made sense to add that story back into the story covering the release notes.

The release notes screen was reprioritized (and has yet to be pulled into a sprint). From a development perspective, we have small, easily testable, and easily reviewable chunks of code. From a stakeholder perspective, we've made progress toward delivering the full feature and arguably have carried out the goal set out in the user story.

We were able to deliver measurable value to the end-user without implementing the full story.

You can't deliver a half-baked cake, but you can deliver half a baked cake.