Simplify Your Life With Static Testing (#PNSQC2021 Live Blog)

 

I confess, the title alone is what caught my attention here and I decided I wanted to jump in and see what this is all about. 

"You're Working Too Hard! Can You Simplify Your Life with Static Testing?"

Okay, what exactly is this? That's what Chris Cowell is describing and how he uses it.

So let's get down to it... what specifically is Static Testing and how do you do it?

Well, the easiest way to think bout this is to get to what static testing is going to be counter to? Is this like how we used "Lint" as a tool for finding issues in C code (and yes, I am that old ;) ). Static testing looks for problems in the source code without actually running it. Thus, yes, Lint was/is a static testing tool. But static testing today goes beyond that. We can use static testing to look for problems in configuration files, XML or markup files, etc. In some cases, these issues could be fixed automatically, or at least suggest fixes and let you, as the user, apply them. 

The real question here is, of course, "can static testing replace functional testing, performance testing, security testing, or other kinds of testing?" No, not really. However, it can complement dynamic testing and as Chris puts it, static testing can help identify risks rather than bugs. 

So where can we use this? Many IDE's have static testing built-in. Any time you see some underlining or alert icons pop up in your code and as we address them as they come up, that's static testing in action. Cool, I never considered it that way! Build tools like Maven, Gradle, and Rake have static testing plugged in. GitLab and GitHub also have this built into their tools (Chris works with and instructs for GitLab, hence why he's mentioning this :) ). There are even Chrome extensions that can do this (Code Climate, never heard of it, but intrigued now).

When static test tools look at code, the tools identify ways that the code might "work" but maybe not the way we intend it to. We could call this a "code smell". Perhaps we might have a coding approach that "works" but may end up causing us problems as things get more complex. 

Static testing can't tell you if you will meet performance goals, but it can/could tell you if there are processes and methods that might add extra time or be wasteful if run as-is.

Static testing may also be able to identify where you may have security issues such as file injection or the potential for Cross-Site Scripting attacks. Code Complexity can also be examined to see if there are overly complicated methods or areas that can be refactored.

Static testing can even help with your documentation. Heck, there are even tools that can help with grammatical issues in text that we have put into the code. as a Grammarly user, I definitely think that's a cool and neat thing to have.

So what does static testing not help with? It can't tell you if your algorithm is effective. It can't really correct iffy implementations, it can't actually help meet performance goals or integration issues, so those are areas where dynamic testing will be needed. Also, Static testing might be a little bit too helpful. Many of the areas that it suggests may not be relevant for our implementation. 

Again, this is meant to be a complementary approach, not a complete replacement for dynamic testing. I can see, however, that there are some definite benefits to looking at additional static testing options. I have some homework to do :).