Use the RCRCRC mnemonic/heuristic to prioritize functionality that needs to be tested.
Transcript for episode 38 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
Welcome to test and code, a podcast about software testing and software development.I am your host, Brian Okken. This week we’re going to continue our discussion what test to write first with a look at a mnemonic called RCRCRC that I used to prioritize which software tests to write first.
RCRCRC was developed by Karen Nicole Johnson. She calls it a heuristic for regression testing, but I call it a great way to prioritize which tests need to be written first or whenever you need to write tests. Each letter stands for something, of course.
They stand for Recent Core Risk Configuration Repaired and Chronic.
Recent is the new features that you’ve just put in, new areas of code.
Core the essential functionality that must continue to work. This includes your products USPs or what does that stand for unique selling proposition, that’s right. The thing that makes your software why people use your software other than somebody else’s, that’s the core stuff.
Risk, areas of an application that pose more risk.
Configuration configuration sensitive areas, code dependent on the environment.
Repaired this is where you’d have tests to reproduce reported defects or tests around functionality that’s been modified to fix a defect.
Chronic areas of the application frequently sensitive to breaking. This is pretty simple, but it’s really pretty powerful. Let’s talk about it in the context of the Cards application that I started talking about in the last episode.
I mentioned last week that I was going to start dog fooding this Cards application trying to use it. The thing that bugged me the most right off the bat was that if I just typed Cards nothing happened; well, it showed me the help. I really wanted to show me the list of cards instead of the help. So I did add that functionality that’s up on Github now. Since that was a recent change, I added a test to the test CLI file, to test its functionality, it was a simple test, it just creates a database and puts three elements in it. And then runs the cards command line with the list argument and without the list argument, it makes sure that it returns the same thing. Easy enough.
The core, so that’s the recent changes, let’s look at the core for this application. It’s a pretty simple application, the API, there’s only like five things in the API, 6 maybe, so we’ve got add, get, list cards, count, update and delete.
I’d just say that all of them are core, but I’ve already got tests for add, at least tracer bullet tests.
Get, I don’t have any for that yet, so I should do tests for that.
Next, I also don’t have tests for count, update or delete, so we should put tracer bullet tests in for those.
The list cards, I probably should put at least a focus test for that, but it is being used during the add testing, so it does have some coverage. And here again, this is the decent way to take a look at coverage tools which we can talk about in another episode. But using coverage to try to find out which bits of your API are not being tested and that can highlight if you look at those and realize that some of those pieces are really important then you should write some tests around them.
The next item, risk, is usually something that is pretty obvious to a team. But I can’t think of anything for Cards that would be at risk right, let me know if you can come up with some test cases around this. It’s pretty new, but for other apps, it might be more obvious. I often think about, especially in an app like this that I’m dog fooding, and again, dog fooding just means I’m using my own application, or my team is, but in this case it’s just me using my own application. But there might be features that I know an important customer uses, but I don’t use on a regular basis, those are risky areas and should be tested a little more thoroughly than others.
Configuration sensitive areas. The cards application so far doesn’t have very much configuration, but there are a lot of applications that do, and looking at those and testing what parts of the application depend on configuration setting or an environment. The Cards application stores its database in the user’s home directory, so maybe there’s something around that that I should be testing. I can’t think of anything right now. Possibly whether or not the database already exists so we could test that. I am depending on a couple of operating system features to find the home directory and to expand the home path, so I want to make sure that that is tested on multiple operating systems. And in that sense, I don’t have specific tests, but I do have things around the tests, and what I mean by that is, I’m in Github to store this, and I’m taking advantage of some of the continuous integration tools that are available to test it on multiple operating systems. And specifically right now, I’m testing with Travis CI and app fair. And both of those are free for open source projects, which is cool. I am using other extra things too, but these are two continuous integration services that allow me to test on multiple operating systems.
Repaired, I don’t have any reported defects yet, so there’s nothing to repair. For the Cards app chronic, also this is too new to have any chronic problems. But actually, let’s revisit these a little bit more. So repaired. Again, I think it’s important if you can to write a test that recreates an issue before you try to fix the issue. But there’s a little bit more than that I think, this is a good idea. So you may have a defect reported on a bit of functionality that doesn’t have very much testing around it yet. So that’s a good place to add not just a test to test the repaired, the reported error, but also some of the other aspects of that function functionality to make sure that it works before and after the fix. Because it’s entirely possible and frequent in your lifetime of a software developer that areas that you fix one thing, fixes might create other bugs, so putting more tests around to make sure that you’re not creating bugs when you’re fixing bugs is a good thing.
And chronic chunks of the code that often break, maybe they need more tests around them. Also, there are some applications that have bits of code that are so old that nobody wants to touch it, because it was designed like 10 years ago and nobody really understands how it works. I personally have the opinion that those are great places to write a whole bunch of tests around and then go through and refactor it, so that somebody on your system understands the code. But at the very least, these are good places to make sure that there’s functionality around.
All right, so let’s say you’ve used this mnemonic the RCRCRC, again it’s Recent Core Risk Configuration Repaired Chronic and that’s it, RCRCRC, let’s say you’ve used it and came up with a list of features that you need tests around, and you’ve written tracer bullet tests for all the bit of functionality that you’ve come up with. But there’s some, like in your repaired section or your chronic section that you just know are a risk, that you just know that there needs to be more thorough testing, not just tracer bullets, how do you do more thorough than just a tracer bullet? That explodes into how to write test cases, but there’s a lot of techniques and there are some that are pretty simple.
In the next episode, we’re going to start going through some of the methodical ways that you can go about coming up with test cases to increase the test coverage for a bit of functionality that you know needs more test coverage. That’s the next episode. I hope you stick with me through this journey of testing the Cards app and also walking through lots of different techniques for coming up with tests.
I’m having a blast, I hope you are too. Please let me know if there are specific things you’d like more clarification on. You can reach me on Twitter at Brian Okken, and also through @testandcode or @testpodcast but, there are also contact forms on both pythontesting.net and testandcode.com. Feel free to contact me that way, but to be honest, Twitter’s the easiest way to get a hold of me, my PMs are open, you can direct message me.
I want to shout out a special “thank you” to all the Patreon supporters that are supporting me in my podcasting journey. Thanks a lot! There’s a link, I think it’s support on testandcode.com you can click and find out more if you want to help support the show, that would be great.
That’s it for today. Thanks for listening and I’ll talk to you next time, we’ll talk about how to fill in test coverage for particular bits of functionality that need more coverage.