Different types of integration tests

Now that you have a complete understanding of what integration testing is, let’s take a look at the various types of integration tests that developers often use.

Method the big bang

The Big Bang approach is one of the most common types of integration testing. In essence, all the units you want to test are shredded together and tested simultaneously. Now, this is useful for small software projects or after completing other forms of testing.

However, it does have its disadvantages. First, if an error or error is found, the tester will not know which module is responsible because they are all grouped together. They will have to isolate some and run the tests again, repeating until they find the error.

incremental

The incremental approach takes two or more logically aligned modules and tests them in a batch. Then, add other related modules and test them together, and so on, until all modules have been successfully merged and tested with each other.

Bottom-up integration

The bottom-up integration approach takes one module at a time from a lower-level module and tests it against the higher-level module until all modules have been successfully tested. This method is very useful for fault detection and location. Also, like Big Bang, it doesn’t waste time waiting for modules to complete before testing. But it’s not perfect. Because the most critical modules (the top-level modules) are the last to be tested, they are more prone to defects.

Top-down integration

Top-down integration is the opposite of bottom-up integration. You test the module once at the top and then at the bottom until you have tested all the modules. The advantage of this model is that the critical modules are tested first, so all major defects can be found and fixed immediately. The downside of this model is that the lower levels have not received enough attention and may not have been adequately tested.

Hybrid integration

A hybrid approach combines top-down with bottom-up. Basically, you will simultaneously test the top module with the lower module and the lower module with the lower module. The top and bottom are integrated at the same time for the best of both worlds.

Integration testing best practices

Now, before you start implementing integration testing, it’s important to have a few strategies in place. Here are some of our recommended integration testing best practices:

Unit test versus integration test sequence

We’ve made it clear that integration testing should follow unit testing, and for many DevOps teams, that’s what’s happening.

The point is that if you follow the principles of agile software development, you don’t have to wait to perform major tests such as integration. When using an approach such as continuous integration, tests are performed continuously. According to Aaron Cois, CI is a way to:

“Constantly merge source code updates from all developers on the team into a shared thread. This constant merging prevents a developer’s copy of a software project developed locally from straying too far when someone else adds new code, thus avoiding catastrophic merge conflicts.”

In the waterfall era of software development, integration testing must follow unit testing. But today, you have more flexibility to choose the right time to perform integration tests.

Unit test suites are separated from integration test suites

Although integration tests can be run as needed, they should not be run in conjunction with unit tests.

Developers need time to deal with business logic problems in the code by running unit tests and getting immediate feedback. This is done to ensure that problematic code is not committed to the main line.

Separating the test suites allows developers to run fast unit tests and store the lengthy integration testing process of building the server in a separate test suite.

Record as much as you can

If something goes wrong during unit testing, it’s easy to figure out why and fix the problem. But because of the scope and complexity of integration testing, which typically spans multiple modules and hardware components, it is much more difficult to determine the cause of integration failures.

To solve this problem, you should use logging to record various operations and data. Logging helps you better analyze failures, record potential causes of failures, and eliminate other causes to narrow down the true scope.

Create test plans for developers

Provide developers with a common shared document that lists a series of logical actions to refer to when performing integration tests. Keep testing consistent across the company and even allow project managers to allocate the right resources to start the integration testing process.

  • Solemnly declare: the article was first published in the public number “FunTester”, prohibit third parties (except Tencent cloud) reprint, published.

Technical articles selected

  • Java one line of code to print a heart
  • Linux performance monitoring software Netdata Chinese version
  • Performance Testing Framework second edition
  • How to perform performance tests on a Linux command line interface
  • Graphic HTTP brain map
  • Automatically turn the Swagger document into test code
  • Probe into the Linear interface testing framework based on Java
  • Selenium 4.0 Alpha update log
  • Selenium 4.0 Alpha update practices
  • How to unify functional, automated, and performance test cases for interface testing

Selected non-technical articles

  • Why software testing as a career path?
  • Programming thinking for everyone
  • 7 Skills to become an automated test
  • How do YOU introduce automated testing in DevOps
  • Summary of Automatic Test failures on the Web
  • How do YOU introduce automated testing in DevOps
  • Testers often use excuses
  • API Testing Basics
  • API Automation Test Guide
  • Future QA test engineer