-
George Adrian Stoica authoredGeorge Adrian Stoica authored
Integration testing
Testing
-
is an important part of software development
-
a way to ensure software quality
-
automated testing allows to develop new features with a minimal effort to check if the software still works as expected
-
testing frameworks
Testing principles
-
testing shows presence of defects (not their absence)
-
testing all possibilities is not feasible
-
testing should be started as early as possible
-
testing depends on the context
Unit testing
-
units are the smallest testable parts of our system (methods, classes)
-
unit tests are concerned with testing the unit in isolation
Integration testing
-
integration testing aims at testing several units / components
-
the size and complexity of such a test is on a spectrum and can be from just integrating 2 units to integrating nearly all components in the system
System testing
-
testing the complete system as whole
-
it can be considered a fully integrated test as it integrates all the components within the said system
-
checks if the system is compliant with the specified requirements
Deployment testing
-
tests the complete system as it would be for actual use
-
complete system should comply with the requirements in the clients' environment
Testing pyramid (2)
-
as we go from the bottom towards the top the tests get more complex and resource intensive
-
the pyramid is a useful reminder that we should have many unit tests, several integration tests and very few system and deployment tests
Types of integration testing
-
"Big Bang" - all of units available are combined together and tested if they work together as intended
-
"Top-Down" - top-down integration allows the team to test the top level units first (stubs)
-
"Bottom-Up" - test the bottom level units first (drivers)
-
"Hybrid" - a combination of both top-down and bottom-up integration testing
Isolating parts of the system
-
to be able to reliably and automatically test parts of the system we need to isolate them
-
the parts need to have a clear contract (the interface used to interact and communicate)
-
when parts of the system that the unit / component we want to test depends upon are not implemented these need to be simulated
-
a simulated component is usually referred to as a mock, stub or fake
-
when the simulated component is using / calling the tested component it is called a driver