I’ve found myself in a test nightmare at work. Why not blog about it?

Testing Basics

Background: at work, things have gone sideways. I’m sure this situation is incredibly common - delivery times shrunk from reasonable to we want it yesterday, and so, testing was thrown out along with maintaining any extant tests. Let me just say that the decision to do this was not mine, and I did, in fact, express my opinion, which was summarily dismissed. So, now ng test just shows me more errors in red than a Giallo film, and if things are pieced back together, likely there will be more red lights than green. I don’t really have a solution to this problem once the tests will actually run. From a quick read, I think there’s some good ideas in Jess Unrein’s article on Don’t Comment Out Your Unit Tests, but I’ll come back to that in a later article. I’ve also got to train up some people who are, as of yet, unexposed to the bliss of the light of testing.

deep breath

Seems like a great time to remember the basics. Let’s go to one of the great luminaries for our source. Despite possibly having a political disconnect with the great Uncle - he’s recently taken to using the acronym SJW, for example - the man knows how to code cleanly, and he knows how to write a test. Lets take a look at an article he wrote in response to an anti-testing article, First-Class Tests

Types of Software Tests

It’s pretty important to lay out some definitions before you get started, right? Right.

Unit Test

This is a test written by a developer that tests whether the code they’ve written does what they wrote it to do. You write something to solve a problem, you want to make sure it actually solves it, right? And wouldn’t it be wonderful if, when something changes (because we all know change is inevitable, yes?) that we have verification that things still work? This right here is what you want. If there are dependencies that are used within the small unit of code that you’re testing, then those tests are no longer unit tests, but integration tests of some kind.

Acceptance Test

An acceptance test is a test written by people representing the business/customer in order to ensure the production code does what it’s supposed to do. This can be from a variety of perspectives, such as user, or making sure the software meets regulations and compliance, but it comes down to: does what you wrote actually do what it’s supposed to do.

Integration Test

For me, things get a bit murky from here on down; I frequently hear Integration and System Test being used fairly interchangably. I’ll do some reading and get back to that in later posts. Now, back to the previously scheduled program: An integration test is supposed to be a test written by the architects or leads that check if everything works correctly from the top down - a plumbing test, if you will.

System Test

Another plumbing test, making sure the internals of the system work.

Micro-test

So, the definition here is a unit test written at a very small scope? Generally, I try to make my tests small in scope, and my code that is being tested also small in scope, so I’ll have to do some research on what exactly the differences are.

Functional Test

A code-level integration test that does actually include dependencies. If those dependencies are slow, then those dependencies are mocked. These tests test slices of functionality - these bits of code work together as expected

That’s it for now. I’ll be back (hopefully) soon with some more testing goodness.