Quality in Testing not Quantity

By -
One of the hardest parts of Continuous Confidence is understanding what brings confidence to our testing. We strive, at times, to find that proper level of confidence. Too often, we talk about Code Coverage. We want to make sure that we are touching everything, and it lifts our confidence, falsely, to the same level of as our code coverage. If we have 60% code coverage, then we have 60% confidence. The issue, however, is after a while, we start to realize, once we get bugs, that we aren't really that confident in our code and then we dismiss testing almost as a chore instead of a tool. So how do we get more confidence? Well, the answer is simple, the process a little more difficult: write quality tests.

Area Coverage

The first thing we need to do, is understand what we are testing. We should be considering Area Coverage instead of Code Coverage. Area Coverage looks at the areas of the application that have tests. There aren't a whole lot of tools out there that will help you do this. I have one I will be releasing shortly, that I use on a daily basis, but ultimately, we can do this however. Once we know that what we are testing applies directly to the requirements, we can start to understand what we are missing. Now, we can start to focus on quality tests.

Test The Change

First and foremost, we want to make sure we are testing what we change. Don't worry about other parts not being tested, unless we are trying to make up for test debt. Sorry about the changes. Test the stuff we are writing to make sure we are covering the logic.

Test The Logic

Next, test the logic. If we have a method that only returns another methods results, the confidence gained testing the latter far out ways the first. So test the latter. Test where the logic is. Test to make sure we are covering all of the logic and code paths within a method. Use constructs to limit our assumptions.

Test the Assumptions

Finally, when we look at the code we are testing, we need to test our assumptions. For example, consider the following code:

if(username.split("-")[1]) {
}

Now, there are a couple of assumptions here. What are they? First, we assume that username is not null. Second we assume that username is a string. Third we assume that when splitting the string, he length of the resultant array is greater than 1. So here is where we can write tests. Or, we can use what we learned and change the code to be hardened. 

Continuous Confidence Focusses on Quality

Ultimately, we want clean and quality code. We want to be confident in what we do. Using testing to teach us what we are missing, allows us to more easily be confident that it won't break when we had it off to someone. This will allow us to be faster. This will ultimately give us Continuous Confidence in future releases.

Comments

Post a Comment

Popular posts from this blog

Not All CI Solutions Are Created Equal

By -
Are there any of you out there who have attempted Continuous Integration, Delivery, or Deployment, and had it fail? Have you ever just given up because it was over complicating things? People were not happy? Believe it or not, this is very common. I have heard many stories where organizations have failed at implementing CI. So first and foremost I want to say: it's ok! We all recognize the value of what we get from doing CI, but in reality, in practice we need to be more practical and pragmatic in our approach. May I offer some counsel. Implement Countinuous Confidence This may seem strange at first, and probably expected since this blog is all about Continuous Confidence, but really, truly, this is he first step. Focus on your confidence points.  Generally, when I see failure in the CI world, it isn't the methodology, but rather the lack of confidence in the process that is causing the problem. Generally speaking, I see people wanting to implement CI in here organization becau...
Read more

Stop Talking About Continuous Integration

By -
There. I have said it. This is the elephant in the room. For years, we as Dev Ops professionals, and as an industry have been talking about how to up our game using Continuous Integration.  We talk about our Software Development Life Cycle (SDLC) or how we need to improve our QA Processes and deliver faster and with higher quality. We start implementing Continuous Integration and we try to implement Continuous Delivery and or Deployment. And you know what happens? We fail to do it the way others did. There are some examples that we try to wedge ourselves into. We try hard to mimic what others have done. And so we fail over time. Some of us, we get to where we want to be, but others...yeah...let's not talk about it! So what should we be doing? We should be talking about Continuous Confidence. We should be talking about what processes and what things are we doing that will help us get better confidence in our product. What will give others better confidence in our product. When...
Read more

Legacy Code: What to do About it

By -
There are a lot of questions around legacy code. If we ask any developer who is new to the organization, they will most likely say: REFACTOR! Our first knee jerk reaction is to not touch the legacy code, so we kind of dismiss the new developer saying that. However, we should look more deeply at what they are saying. The Code is Messy Generally, when dealing with legacy code, it is messy! Let's face it, when we start writing code, we ignore certain design patterns for others because there isn't a need. Once we get large enough, something has to be done about it. We need to stay focussed. If we feel that we are assigning one senior developer to fix legacy code, while 50 others are still using it, we will,never fix the code. Continuous Confidence comes from looking at the code and feeling calm not erratic. The Code is Antiquated When we hear refactor, His might mean as well that the code doesn't follow today's standards. So how do we make it so? We need to refactor...
Read more