What are unit testing and integration testing, and what other types of testing should I know about?
I've seen other people mention several types of testing on Stack Overflow.
The ones I can recall are unit testing and integration testing. Especially unit testing is mentioned a lot. What exactly is unit testing? What is integration testing? What other important testing techniques should I be aware of?
Programming is not my profession, but I would like it to be some day;stuff about production etc is welcomed too.
Off the top of my head:
- Unit testing in the sense of "testing the smallest isolatable unit of an application"; this is typically a method or a class, depending on scale.
- Integration testing
- Feature testing: this may cut across units, and is the focus of TDD.
- Black-box testing: testing only the public interface with no knowledge of how the thing works.
- Glass-box testing: testing all parts of a thing with full knowledge of how it works.
- Regression testing: test-cases constructed to reproduce bugs, to ensure that they do not reappear later.
- Pointless testing: testing the same basic case more than one way, or testing things so trivial that they really do not need to be tested (like auto-generated getters and setters)
should I be aware of any other important testing of my code?
These are some of the different kinds of test, according to different phases of the software lifecycle:
- Unit test: does this little bit of code work?
- Unit test suite: a sequence of many unit tests (for many little bits of code)
- Integration test: test whether two components work together when they're combined (or 'integrated')
- System test: test whether all components work together when they're combined (or 'integrated')
- Acceptance test: what the customer does to decide wheher he wants to pay you (system test discovers whether the software works as designed ... acceptance test discovers whether "as-designed" is what the customer wanted)
- Usability test
- Performance test
- Load test
- Stress test
And, much more ... testing software is nearly as wide a subject as writing software.
The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use.
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Check sites for more information. There is plenty of information out there as well from sources other than Microsoft.
The other important technique is regression testing. In this technique, you maintain a suite of tests (called the regression suite), which are usually run nightly as well as before every checkin. Every time you have a bug fix you add one or more tests to the suite. The purpose is to stop you from re-introducing old bugs that have already been fixed. (The problem is surprisingly common!)
Start accumulating your regression suite early, before your project gets big, or you'll regret it. I surely have!
There are different levels of testing corresponding to what stage you are at in the software development life cycle. The highest level is requirements analysis and the lowest level is implementation of the solution.
What is unit testing?
- Unit testing assesses the software in regards to its implementation.
- We focus on testing units of a program (ie. individual methods) and disregard who calls/uses these units. Hence, we essentially treat each unit as a stand alone unit.
There are many unit testing tools, one of the most popular one is JUnit.
When performing unit testing we want to construct a test set (set of test cases) that satisfy a certain coverage criteria. This could be some structural coverage criteria (NC, EC, PPC etc.) or data flow criteria (ADC, AUC, ADUPC etc.)
- Note that unit testing is the lowest level of testing because it assess the actual code units produced after implementation. This type of testing that is done before integration testing.
- Efficient unit testing helps ensure that integration testing will not be painful, since it is cheaper and easier to spot and fix bugs when doing unit testing
What is integration testing?
- Integration testing is needed to ensure that our software still work when two or more components are combined.
- You can perform integration testing before the system is complete.
- The class integration test order (CITO) problem is associated with integration testing. CITO has to do with the strategy of integrating components. There are many proposed solutions to CITO such as top down integration, bottom up integration etc. The main goal is to integrate components in a way that enables efficient testing and the least amount of stubbing, since writing code stubs is not always easy and takes time. Note that this is still an active area of research!
- Integration testing is done after unit testing.
- It is often the case that the individual components work fine but when everything is put together, we suddenly see bugs appearing due to incompatibilities/issues with interfaces.
Other levels of testing include:
- This type of testing is given a lot of importance because developers commit changes to software quite often typically, so we want to make sure that these changes do not introduce bugs.
- The key for effective regression testing is to limit the size of the regression tests so that it does not take too long to finish testing otherwise the test set will not finish running before the next commit. We must also pick effective test cases that will not miss bugs.
- This type of testing should be automated.
- It is important to note that we can always keep on adding more machines in order to counteract the increasing amount of regression tests but at some point the tradeoff is not worth it.
- With this testing we assess software in relation to the provided requirements, basically we see if the software we have produced meets the requirements we were given.
- This is usually the last type of testing done in the sequence of software development activities. In consequence this type of testing is done after unit testing and integration testing.
Unit testing is simply the idea of writing (hopefully) small blocks of code to test independent parts of your application.
For example, you might have a calculator application and you need to make sure the addition function works. To do this you write a separate application that calls the addition function directly. Then your test function will evaluate the result to see if it jives with what you expected.
It's basically calling your functions with known inputs and verifying the output is exactly what you expected.
First two search results on google for 'types of testing' look comprehensive
The ones I think are most relevant. See here.
This was an entry I wrote: Different Types of Automated Tests.
Unit Testing: The testing done to a unit or to a smallest piece of software. Done to verify if it satisfies its functional specification or its intended design structure.
Integration Testing: Testing the related modules together for its combined functionality.
Regression Testing: Testing the application to verify that modifications have not caused unintended effects.
Smoke Testing: Smoke testing is verified whether the build is testable or not.