Definition: Unit, Integration, and Functional Testing
Gojko Adzic describes defining tests with the following statement:
“It’s not important what you call it, but what it does.”
This is a great way to approach defining tests. The truth is that there are many different definitions out there, and it’s often difficult to isolate a single meaning from the large variety of perspectives and roles that exist within the development community.
In this post, we’ll go over the differences between unit, integration, and functional testing. A programmer could spend a lot of time improving test automation (it’s a huge field), but today we’ll try and cover these three.
Just a note: We will not show you how to write tests in this post. Rather, we would like to clarify what each form of testing means, what it’s purpose is, and how it’s used in testing applications.
Unit Testing
Short definition: Simple (and quick) tests that allow us to identify the precise point where an error occurred.
As the name suggests, unit testing is the act of testing a “unit” in your application. A good thing to remember is that unit tests are meant to test your code, not high-level features. This means they will test the smallest units of functionality in an application, usually a method or a function.
When you create a unit test, it should be focused upon one specific function (or a small group of functions). Therefore, these tests should be short when you run them. As in, 1 millisecond per test short.
The whole point of running a unit test is to test the individual building blocks of your program’s functions. The more concise a test is, the easier it is to pinpoint the exact location of an issue.
Unit testing is important for identifying common mistakes early on in development. And, it will make testing at higher levels much easier later on.
Integration Testing
Short definition: Tests that focus on whether units of your code work together.
This is the next level of testing. If unit testing focused on individual units, integration testing’s main point is to ensure those units of code (or components) can be successfully integrated together. The idea is to test the pieces that will eventually be combined to make up larger parts of a program.
The point is to identify any errors that occur as a resultof integration.
Integration testing will help you find issues that unit testing can’t. For example, errors that occur as a result of environment would not be identified during unit testing. Integration tests can use threads, access databases, or do anything that is required to make sure your code will work correctly in spite of any environment changes. Your testing scenario should be realistic to mirror how that particular component would behave when your program is actually run.
An important thing to remember when conducting integration tests is that they are not as reliable as unit tests. Failures are much hard to diagnose and the tests are harder to maintain because they touch much larger portions of code. Additionally, they do not guarantee that a feature works.
Functional Testing
Short definition: A test to verify that your program works the way it is supposed to.
Defining functional tests can be difficult, as some definitions qualify them as a type of integration testing. However, to avoid any overlap, it might help to think of functional testing as a type of testing, not a level of testing.
Functional testing is meant to verify in a controlled environment whether your application does what it is supposed to do. You are validating whether your program will perform the functions it was designed to carry out. The perspective shouldn’t be from the programmer’s point of view, but rather, it should focus on the results for the end-user.
They are tests created to test specific behavior and are concerned with the external result, rather than the state of the internal program.
Look at it this way: it either works or it doesn’t.
Another no-jargon way to think about it…
Imagine your are building a bike (your final application). Your bike is made up of larger parts that are assembled to create the final product.
For example: a body, a system for braking, and a system for pedaling.
These are three different components that are constructed from smaller parts (or units).
Based on these components, our units would look something like this:
Body: a seat, handles, and a frame.
Brake System: brake wire, braking pads, brake handles
Pedaling System: pedals, chain, gears, tires, etc.
Now, imagine that you are testing them.
1) First, you would test your units in isolation.
Test that your units are in proper condition. For example, your brake wire is strong and won’t snap.
2) Then, you’d combine those units to see if they worked when combined.
Check that when you pull a handle, your brake wire not only responds, but also stretches the correct amount.
3) Finally, once you have checked each of those systems (or modules against each other) you would make sure your bike did all the things a bike is supposed to do.
You can pedal forward and backwards. You’re able to stop. When you want to turn, you can go both right and left. You can go both backwards and forward.
Did you find this post helpful? Would you define these a different way?
Share your thoughts here or on Facebook. Or, tweet us directly @testomatocom.
