Unit testing is a form of software testing where you test small individual “units” of code. Each unit tested might be associated with a small sub-section, like a function. The associated control data, usage procedures, and operating procedures, are tested to determine whether the unit is ready for use, or at least the next set of testing, where we test multiple units together to make sure the whole system works.
Typically these units of code are a method within a class, or possibly the whole class or interface of a class.
This is often considered the lowest form of testing, and is not dependent upon the whole of the code working well. However, the idea is to test small units to quickly find bugs and reduce the chances of bugs creeping into larger sections of code.
Testing Automation
These tests are often automated, which makes running them easy, especially after changes are made. This means a large number of tests can be run, and verified, finding potential bugs faster than having to run manual tests.
But not only is it faster, it is much cheaper. Because the tests produce predictable results and can be automated, you don’t have to tie up a developer with running these tests. You can run them overnight, or even before you push them into a code repository. By running them quickly, you get a faster answer as to the worthiness of your code before you put them into further testing methods or production. You only need a developer if your test fails for some reason once you choose to run the test.
Using Parameterized Tests (PUTs) allows you to run the same test multiple times with different inputs as the parameters. The idea is to not test with just one set of data, but with different data, and even different data types including some which should fail. This way you can verify that unit will pass when it should, and fail (appropriately) when it should.
If you were to write a method that serves a person a drink based upon the number they ask for, you might test by asking for a single drink. However, would it work if the person asks for 999 drinks? So you put this in your PUT to see if it handles that correctly. You also might test for 5 drinks (legitimate) and -1 (not legitimate). This way you know if your unit is properly functioning.
There are libraries and applications which help with PUTs. These can be used to help easily track and manage your tests, letting you know when a system succeeds or fails.
Test Early and Often
Unit tests should be written early in the development cycle, as it makes for finding bugs faster and easier. It is generally also considered much cheaper to find bugs early on in the development life cycle.
Unit testing may take up as much, or even more, lines of code than your developed data. However, the idea is to make up the time lost in developing tests, by reducing the amount of time spent trying to debug.
Additionally, any time you modify your code, either in expanding it or refactoring it, running your unit tests will make sure that it still produces the same results. This is especially important on large complex systems. A set of code might be refactored to improve performance, and you want to make sure you don’t change the results the code is supposed to generate.
Other Types of Testing
Other types of testing, such as integration and user testing, should still be done however. This is because we are only testing individual units. We cannot tell how multiple units will work together. Nor do we have any idea on performance of the application, or how a user operates it.
Therefore, while unit testing is a very good form of testing, it isn’t the only testing method, and it cannot cover all forms of potential problems.
Some languages have built in tools for doing unit testing, like Python and Ruby. In other languages, unit testing is not built into the language itself, rather, it relies on external libraries. Some of these libraries are well defined and used for languages like C3, Java, and PHP.
Who Should Write Unit Tests
This is always an interesting question. Should it be the person who wrote the module (often it is), or another developer so you don’t have bias in your tests?
Often the person writing a test, will be an intermediate to senior level developer. This is because what is tested, and the test itself, needs to be of a high quality. If you have a junior developer writing your test, they may miss important cases to test because they don’t have the experience to know how code responds to different types of data.
For the same reason, a junior developer can start to quickly gain a lot of insight in helping write unit tests as they will see all of the different types and combinations for data and how it will work when applied to a larger and more complex program.
Unit Tests was originally found on Access 2 Learn
