Blog

Full Integration Testing – Why it’s so difficult by Admin on Feb 22, 2016

If you search on the Internet for a definition on Integration testing, you will find many. I particularly like a portion of Techopedia’s definition for integration testing.

Techopedia defines Integration testing as “a software testing methodology used to test individual software components or units of code to verify interaction between various software components and detect interface defects…”

Integration testing is particularly useful when it comes to testing the guts of an application’s back-end service methods and core business logic. The back-end business logic is where complex calculations and logical decisions are executed in small to large transactions that end up affecting the state of small to huge quantities of data within a back-end database.

Even though integration testing is a great methodology for fully testing a software application’s back-end business logic, it is rarely used to this effect because the level of test data required to test such code complexity is often too difficult to create and maintain.

Let’s take a shopping cart application for example and look at two different integration tests.

One integration test wants to validate the business logic in a service method that adjusts the stock level of an item when a user adds or removes an item from their basket. The test may need test data for the following entities:

  • Store
  • Vendor
  • Item
  • Item Stock
  • Item History
  • User
  • Basket
  • Basket Item

A different integration test wants to validate the business logic in a service method that creates an order from the items found in a user’s grocery basket and computes the total. The test may need test data for the following entities:

  • Store
  • Vendor
  • Item
  • Item Stock
  • Item Discount
  • Coupon
  • Special Offer
  • Tax
  • User
  • Address
  • Basket
  • Basket Item

In these two integration test examples, there are eight or more entities that must be populated with test data and the test data must be populated and stored with exactly the right parent-child relationships with referential integrity, otherwise the tests can not be successfully executed.

Integration tests that require this level of data are rarely implemented because once the level of test data reaches beyond three entities, the time and resources necessary to create and maintain such test data becomes too complex and overwhelming regardless of the data being generated by hand or pruned from production data.

I have given only two examples of possible integration tests necessary to test the back-end business logic of a shopping cart application. In actuality, for a complete shopping cart application, there may be hundreds of service methods each containing similar complex business logic that need to be fully integration tested.

This is why supplying test data for hundreds of unique integration tests is so difficult. The rules of integration testing are that the test data that is loaded for the test should be loaded independently from the test data that is used for any other integration tests. This is because test data being used for one test can impact the outcome of another test.

So the best way to load test data independently for each test is to generate an integration tests’ test data in real time, so the test can have the complex test data it needs at the moment it is executing. But it is very difficult to generate test data with parent-child relationships with referential integrity and even more difficult to generate it in real time.

What if an integration test could receive exactly the test data it requires and received the test data in real time? That would mean the test data would need to be synthetically generated with the flexibility of having realistic and patterned values generated so that the test could have exactly the test data it requires. It would also need to generate test data for all lookup, parent and grandparent relationships with the complete ancestry of test data – all with referential integrity necessary to run the test. And what if all of the test data could be generated and utilized in one or two lines of code within a given test?

Well… If this were possible, it would revolutionize the way integration tests are created and run!

  • It would mean that integration testing complex business logic needing complex test data is no longer a difficult challenge but an opportunity to fully test the code.
  • It would make it possible to run each integration test autonomously from all other tests.
  • It would make it possible to fully integration test the complex business logic of an entire application.
  • It would mean that code releases with new features get implemented and pushed to production faster and on time with the confidence that the code logic is fully tested.
  • It would mean that code modifications would not cause new bugs to reach production because the code would be fully regression tested.
  • It would mean testers within an organization would become super stars, gods even, because on a daily basis, they would be insuring that their companies software applications are fully tested and ready for prime time all of the time.

This is not a dream; it’s just the new way of doing integration testing with GenRocket. The revolution in test data generation and software testing is already here.

To see how this can actually be done, take a look at our Full Integration Testing Technical White Paper  (scroll down to ‘Want to learn more’).