What is an integration test?

588 views

I’ve recently become aware of a company that was running an integration test, but the test went out to all users in the production environment. What type of test is this?

In: Technology

5 Answers

Anonymous 0 Comments

I have found in my 20 years of experience that companies do not name their tests correctly, but here are the most industry accepted meanings.

The basic Idea is that there are 3 main tests.

1. Unit tests. These are automated tests that check the smallest parts of the code possible
2. Integration tests, they check that the units work correctly together
3. Regression test, they check that new changes did not break stuff that already worked

Integration and regression tests are sometimes automated, and sometimes done by tester

Anonymous 0 Comments

Integration test is to validate that any systems, applications, software that you use in your job – hasn’t been affected by the new stuff they are bringing in. They want you to continue doing all your normal work, and if you notice something is broken, let them know. Usually integration testing is not done in production tho.

Anonymous 0 Comments

The HBO integration test email, by any chance?

Like others have said, there are different meanings. Usually integrations refer to two or more different systems talking to each other. For example, you might have a 3rd party company that sends out bulk emails.

To use them, they give you something called an “API” which is sort of like the control panel on a vending machine. On a vending machine, you put in some money and press the button for what you want, and the vending machine does a bunch of stuff and spits out that item you wanted.

In the computer world, you have computers that offer services (like sending bulk emails). So instead of putting in money and punching buttons, you put in a list of a million email addresses, and the message you want to send to all of them (all of this goes into that “API”). Then that service does the job you requested.

So an integration is usually just one computer system talking to another one’s API. And in this case, someone probably sent over a list of real customer email addresses instead of the list of test email addresses.

Anonymous 0 Comments

This isn’t an answer (other people have very clearly explained the test pyramid), but I just love how this incident has managed to unite the entire internet

Anonymous 0 Comments

Software application testing can generally be divided into four different levels. The lowest levels are easiest to automate, whereas the highest levels require human verification.

1. Unit tests.
This is the smallest level, where each component within a software application is tested **individually**, without relying on any other components. These tests are automated and can (usually) be run in a matter of seconds. In software, components often interact with other components. In the case of unit tests however, these other components are substituted with “fake” other components that always have the outcome one would expect if said component was working correctly. This process is called “faking”, “mocking” or “stubbing”.
*Example: if I press the Post-button, it should send the contents of my form to a (fake) form handler.*
2. Integration tests.
On this level, we’re testing how the **different components of a software application work together**. These tests can be automated, but usually take long to execute because they require multiple components to be up and running.
*Example: if I press the Post-button, it should send the contents of my form to a form handler, which should then store my post into a database and redirect me to a new page.*
3. System tests.
On this level, we’re testing our **entire application**. System tests are done in an environment that closely resembles the live (“production”) environment. They do not only verify that the application is functionally working correctly (this part may be automated), but also that it matches the (technical/functional/business) requirements set by the client/product owner. Testing at this level is preferably done by co-workers who were not directly involved with the development of a feature (Four Eyes Principle).
*Example: if I go to the comment section on the site, I can post a comment and be redirected to said comment, all according to the specs the client agreed on.*
4. (User) Acceptance tests.
The final level, in which the **client**/product owner determines if the application matches their **needs** and if it is ready to be released. If we pass this stage, the application is ready for deployment to production.
*Example: does the comment section match our needs and wishes? Was this agreed upon?*

I noticed some people mentioning regression tests (ensuring old features still work whenever a new feature is released). These aren’t so much a separate level, as they test a different scope *within* a level (old functionality vs. new functionality). Regression testing takes place on all levels.

System and integration tests are often mixed up. Integration tests are usually performed in a short-lived, containerized environment that is created on the fly and destroyed after the tests, whereas system tests are performed on a more long-lived testing environment. In your example, it is likely that someone messed something up in the config of a test environment and somehow used user data from a live/production environment.