There is an old computer science adage that the sooner you find a bug, the less impact it has. In this post I want to talk about the first test that every programmer does, and why you need to be as purposeful with this test as possible.

No matter who you are, or how well you test your code, there are three very essential parts of the testing that aren’t talked about much. I wrote about one of them earlier with this editorial on Testing In Production. Obviously not your only testing, but it is the place were you learn the most because this is when real people/systems/environments hit and you need to treat it like an ongoing test. The first test we all run typically is to see if the code compiles. If it won’t compile, we know what to do then.

The second test

The next test is what we do after our code compiles, and I don’t actually know that I have seen it mentioned anywhere in name, thought I did find an article on “vibe testing”. The idea of adding a test to check to make sure software works from a human experience is a good one.

But I am talking about when you first write each line of code and execute it. Does it feel like it is working? Even before you attempt to validate or prove that software is working well, you ask yourself, is this doing what I asked it to do?

The steps you take next may be different if it feels wrong versus if it feels right.

Feels like it is working?

This is about math, right? We are told what to create and we create it. Even when we are the person telling us what to write, when we start typing we know what we want to outcome to be (even if you are using AI to create code, you don’t just say: “just write something fun for me.

So say you have gotten a request to answer: “How many orders has our company shipped?” You write a SQL query like the following:

SELECT COUNT(*) FROM Sales.ShippedOrders;

You expected to 1 row back. If you get 0 or > 1, that certainly won’t feel right and you will start looking at how that might be possible.

Then you will look at the output. Does the output seem right?. 0 rows? this can’t be right 10 billion rows returned? Does that seem right? Checking to see if your code does what you expect is a very non-scientific test. You likely haven’t written tests yet, and may not have specified them. This may actually just be a query you are writing on an ad-hoc basis and no other tests are going to be done.

So you went to the object manager, found a view that is called Sales.ShippedOrders and ran that query. But you know that can’t be right.

It feels wrong.

So what?

Usually this affects your next step. When the answer feels wrong, it almost always is a sign that you need to immediately question what you are doing. “Why might this be wrong?” “Am I doing this right?” “Why does this feel wrong?” “Did I do what I thought I was doing?”

Without this sense for what your answer should be, you might spend hours writing tests and showing how that query to count the number of rows in that table is indeed 10 billion. All is great, except that table was named incorrectly, or has been overloaded by years of poor practices. Or you might get 0 and realize this is only here for backwards compatibility reasons. (Or maybe it is empty during some load process.)

This is a simple example, but it isn’t completely unrealistic. There are database objects, APIs, code, tools, etc that all do things that don’t make sense either by bad naming or just the evolution of the coding eco system. If your answer doesn’t at least feel right, probably best to take a look at why. Ask a question or two. “Does anyone have a feel for how many sales our company does in a year?” “200, yeah, something is wrong here”

Or think about building a UI. The buttons on the screen are triangular shaped. Maybe this was even in the spec, maybe it is something you or a team mate is trying out. But if feels awkward as you try it. In each case, these are checkpoints to say “really?”

So when you get the feeling that something is wrong, investigate. Whether you are using a test driven development process and have already created unit tests that have been passed or not, if it feels wrong there is a definite chance it is wrong.

Feels wrong doesn’t mean it is wrong

There actually may have been 10 billion shipped orders in this table even though this person said 200. They may be thinking incorrect. This may be for a revival of the old McDonald’s signs that used to click over after every billion burgers were sold. But if you feel like it is off, and then write unit tests to validate the data that will pass with too wide of a range of values like 0 – 10 billion…you have wasted time.

There are two parts of writing software. The specification (if written before the code, it tells us what to write, and after it can tell us what we wrote), and the code. You can write code that is correct based on bad specifications. I always think back to a Thanksgiving Friends episode when Rachel said about recipes. “If it says boil two cups of salt, you just boil two cups of salt.”

This is part of your job as a programmer sometimes. You can (and should) protest when you get weirdly incorrect instructions for building software. “Are you sure you want triangle buttons? This is very not standard.” Yet, if the customer (actually) wanted them triangles, they had their reasons. But if it was a typo, you can save a lot of time by saying “this feels wrong.” Sometimes you have to demonstrate that salt won’t actually boil, but often you get a “that should have said salted water, sorry for the confusion.”

Reminder: Compilation, Feels good, and Production should not be your only tests

Like I started out, there are three tests you always do if you are creating and shipping software of any sort.

Starts with compilation then check to see if it feels it works, and then giving it to users to see how well it works. The first two are not a truly disciplined test, it is just something you should think of as you are building something.

Production testing is just giving the code to users and letting them do real work with your code, if possible (and their first test will be “does this software feel like it does what I needed it to?” There should be as much instrumentation as you can possible have to help you support them. (assuming your users know about what is being tracked, of course.)

While “feels right” is a terrible test by itself (much like “works on my machine:). It is just part of the many types of tests you should be doing before you foist your software on unsuspecting users. This article on the Types of Software Testing us a good place to see many of the other types of tests.

But you should never just go “this feels wrong, it is probably just me.” It probably isn’t just you… though it might end up being just you they blame (especially when you say “yeah, I wondered about that, that did feel wrong”