When it comes to building software for other people – regardless of if it’s a WordPress plugin, a mobile app, a desktop app, or something else – one of the most important things we can do is to test the project.
And I know: Talking about testing is boring. It seems to be disconnected from the act of implementing a solution and being able to say “Hey, look what I did!”
Testing, on the other hand, is sitting there making sure our code works. But, please, our code definitely works because we can see it happening, right? The truth is, we know this isn’t the case.
And so we’ve got all of these various tools to help us write unit tests, acceptance tests, behavioral tests, we grab groups of people and have them perform usability testing, and all of that’s important.
But before doing any of that, I think it’s important that we actually understand the rules of the problem that we’re aiming to solve. Sometimes we see this referred to as domain rules; sometimes, we don’t see it mentioned at all.
Domain Rules: What We Codify
Not long ago, I wrote a post about writing tests down on paper and going through, at the very least, to make sure this checks out. For small projects, this works great.
In fact, it’s something I’ve been doing this week:
But when doing this, I realized that one of the primary problems I was experiencing when being unable to properly rendering the results of an operation on the screen predictably was because I was unclear about the rules for how the program was supposed to work.
Don’t get me wrong: I know what the project calls for and I know how it’s supposed to work, but when working with a large dataset, there are times in which the results I was seeing was unpredictable.
Planning an interfaces and class implementations.
And after stepping back out of the code and the testing and the notes, it became immediately clear that the rules around what constitutes certain types of results were unclear.
Rookie mistake, right?
How often, though, do we get so close to a project that we forget to take a step back and look at the rules that govern the project? After all, isn’t the first thing that we’re supposed to do is look at the rules that we’re suppose to convert into code?
There’s a disconnect that happens, though. Sure, sometimes the client isn’t sure of all the rules that are implied with their project. Sometimes, though, we’re also so eager to jump into what we’re doing that we forget to include that in our development process.
Ultimately, this post is probably a reminder for myself more so than anyone else. But if you’re reading this and are working through a similar problem or you’re about to start a project, don’t forget to detail the rules you’re going to codify.
It can save time (and perhaps frustration) through the project.
