What’s Unit Testing?
I don’t need to to tell you how annoying dealing with a bug is. You write out some code that you’ve written a hundred times before, you’re certain it’ll work and then BAM, you got some funky data coming through this function you built or your entire application straight up goes “Nope. Something’s wrong here, and I ain’t gonna work until you fix it, bucko”. Now I understand why you might not want to slow yourself down with testing when you’re in the “coding zone” and you’re cranking out lines like a machine, but testing your code constantly is what’s going to help you identify bugs quickly.
Now, there is a TON of ways to test your code from different approaches like static testing, dynamic testing, or even “box” testing and there’s also different levels of testing like integration and system testing. Then you get to the real meat of how to actually test your code using different methods or techniques like alpha and beta testing, compatibility testing, security testing (this one is especially important), et cetera. We’re just going to be doing a general overview on one type of testing, Unit Testing!
You still didn’t mention what unit testing exactly is.
I will here! To boil it down, unit testing is testing every block of code (or “unit”) you write to ensure it achieves intended results. Code is continuously written to make sure all the tests pass. This falls under the umbrella of “test-driven development”, where code is expanded upon just to pass written tests. Unit testing is applied to many forms of programming like functional programming or object-oriented programming. The more tests a unit passes, the more complex that unit’s testing will be to make sure things like “edge cases” are accounted for. Unit testing also often uses things like fake data (the Faker gem is a very popular library in Ruby for generating fake data) to isolate the block of code from the rest of the application to ensure its functionality.
How does one go about unit testing?
As I’ve mentioned earlier, there are different approaches to testing. I’m sure you’ve seen the term “agile approach” before as it’s the most popular of the bunch, but there are others like “waterfall”. For now, I’m only going to talk about agile and waterfall. Before this, though, I want to mention that when I say “approach”, it really just means a set of rules on how to do software development.
The agile approach, as you may have guessed, is a very flexible way to develop software. I know I mentioned approaches being a “set of rules” in the last paragraph, but the reality with agile is that there really isn’t any (that would pretty much defeat the purpose of calling it “agile”). Instead, agile is really tailored to what works best for your team. There are, however, methodologies for agile development. I recommend reading up on what Scrum and Kanban is as they are the most popular methodologies of agile development and even often overlap each other so you can get a better idea of how unit testing may be implemented.
The waterfall approach is an actual rigid, structured way to go about developing. Think of it as a checklist, where a programmer may first write out code, then set up tests, launch the tests, log the results, and test again if needed. Wikipedia actually has a pretty good sample of what a typical Waterfall model looks like. Waterfall is often times not used, though. Clients have to be 100% sure what their final product will look like and if you’ve ever worked with anyone ever, you’ll know that this is almost never the case and something else will come up.
