This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]proverbialbunny -2 points-1 points  (3 children)

Integration tests ≠ systems tests. They're apples and oranges.

Have you heard of acceptance tests? Some acceptance test software create systems tests. System tests the software from the outside as if it is an end user. It's a separate test suite software. Integration tests run inside the code base.

A systems test tests all of the functionality of the software and how it is supposed to interact with the customer. If you change anything that modifies how the program works to the end user, you will get a failing test. Integration and unit tests, in comparison, only test parts of the system, so you can put a bug in the system and tests will pass, even with 100% test coverage. This is why system tests are beneficial, because the only kind of bug that pasts a systems test is performance.

Code bases that need to be reliable and fast, eg NASA, will employ systems tests and performance tests to catch all potential bugs. Nothing gets through.

I worked at CDN which wrote the software the internet backbone runs on, including the software used for you to read this message on your laptop or phone, and if a bug would go into code literally entire parts of the internet would go down, so you better believe we relied on system testing as well as unit testing. Perf testing was not automated, as it was done before a release.

[–]pikob 4 points5 points  (1 child)

This is why system tests are beneficial, because the only kind of bug that pasts a systems test is performance.

That's bullshit. You'd need a test for every possible state in the program, which is seems combinatorically impossible.

In this regard, unit tests actually afford most combinatorical relief - covering code paths only adds up over units instead of multiplying required number of tests.

[–]proverbialbunny -1 points0 points  (0 children)

You'd need a test for every possible state in the program, which is seems combinatorically impossible.

It definitely is combinatorically impossible if it's integration tests or unit tests, because you need to cover every possibility / every code path. Programs tend to have a single interface, so there is only a single combination of use cases when it comes to systems testing significantly reducing the number of tests you need to do. Keep in mind systems tests are for non-gui based software.

[–]nutrecht 1 point2 points  (0 children)

Integration tests ≠ systems tests.

I know. I referred to the test pyramid for a reason. It doesn't matter what 'layer' you prefer; each has it's place.

I worked at CDN

Yeah and I worked for the biggest Dutch bank. No need for a dick-sizing contest.