What is a Unit Test? First off, what is a Unit? Basically a Unit is a significant piece of a larger project. Unit Testing is specifically programmatically testing the back end programming or the front end programming and interface. These are typically just referred to as the Back End and the Front End. The Front End is often spoken of as including the “Design” (aka look and feel). Furthermore, a Back End designed to work with more than one Front End typically has a formal API (Application Programming Interface) and it is common to speak of the Back End simply as “The API” (i.e. “the API is rebooting right now”).
Now that we have all that spelled out, Unit Testing is almost always testing an API. A matching program is written to interface with the Back End and provide test data and check the response for validity. The best setups run the tests ever time a change is compiled or saved to the Back End code. This assures that the change in one part didn’t break that feature, or some other related or even supposedly unrelated feature. This is especially true when changing the structure of a database, since the effects are not always immediately obvious. Unit tests often save hours of trouble shooting because they reveal problems much closer to when they’re caused. And they save time at the end of a project, since it’s extremely time consuming and error prone to manually test projects after everything is written, and when the tests are all passing, running them one last time is very fast, so you’re project delivery time is much more predictable with good Unit Testing.
When a Back End only interfaces with one Front End, its functionality is often tested by testing the front end, kind of using the Front End as a manual test of the back end unit. Since unit testing a Front End is far more complex they are often not setup with automated unit tests, rather, they are manually tested using a checklist, or in some cases, just “spot checked” randomly hoping to catch bugs before the client or customers see them. Definitely better to have a methodical way to test, either manually, or with unit tests.
Mostly Unit Testing is implemented through TDD, Test Driven Design (aka Test Driven Development). TDD means the programmer writes tests that try to get specific responses from the API and they fail. Then he/she writes an API that provides the expected responses, so the tests pass. Then more tests are added, and more API features to match the tests, until all the desired features are functioning properly.
Take note of the “one feature at a time” design paradigm. This is part of Agile Development. If the project scope changes, all the unimplemented features may not need to be written, and everything that is already written is fully functioning. This makes much less waste when projects change (they almost always change). It is also easier to determine and explain the cost to change the scope of the project to a client because working unit tests prove to the client that progress has been made, justifying charging the cost of features they choose to remove from the project.
Another paradigm worth noting is Lean Development, which basically says to only build what you need. This may sound like Agile, however, the difference is that Lean eliminates features up front, reducing the complexity of the plan from the beginning, and Agile is a method of following a plan once that plan is in place. Lean also reviews projects to prevent and remove “feature creep”, that is when developers make features more capable than they have to be, therefore increasing the complexity and cost of developing and maintain those features. The best way to make code work well is to eliminate unnecessary code, keep it Lean.
So Unit Testing is a significant piece of the Lean & Agile Project Development of complex programs and web sites. It also happens to be a good idea for almost any project, even if it only has one unit, test that unit.