Integration tests check whether your application works and presents properly to a customer. They seek to verify your performance, reliability and of course, functional requirements. Integration tests should be run against any of your developer, staging and production environments at any time.
Writing good tests proving your solution works can be challenging. Ensuring these tests to perform the intended actions and to exhibit the expected outcomes requires careful thinking. You should consider what you are testing and how to prove it works – both now and in the future. To help you create tests that work and are maintainable, here are 9 Do’s and 9 Don’ts to contemplate:
When Creating Integration Tests Do…
1. Consider the cost vs. benefit of each test
Should this be a unit test? How much time will it save to write this test over a manual test? Is it run often? If a test takes 30 seconds to run manually every few weeks, taking 12 hours to automate it may not be the best use of resources.
2. Use intention revealing test names
You should be able to figure out or at least get an idea of what a test is doing from the name.
3. Use your public API as much as possible
Otherwise, it’s just more endpoints and calls to maintain when application changes are made.
4. Create a new API when one isn’t available
Rather than relying on one of the Don’ts…
5. Use the same UI as your customers
Or you might miss visual issues that your customers wouldn’t.
6. Use command line parameters for values that will change when tests are re-run
Some examples include items like site name, username, password etc.
7. Test using all the same steps your customers will perform
The closer your tests are to the real thing, the more valuable they’ll become.
8. Switch your system under test back to the original state
Or at least as close to it as you can. If you create a lot of things, try to delete them all.
9. Listen to your customers and support team
They will find ways to use your systems that you will never expect. Use this to your advantage in creating real-world beta tests.
When Creating Integration Tests Don’t…
1. Write an integration test when a unit test suffices
It’ll be extra effort for no benefit.
2. Use anything that a customer cannot use
Databases, web servers, system configurations are all off limits. If your customer can’t touch it, your tests have no business touching it either.
3. Access any part of the system directly
Shortcuts just reduce the quality of your tests.
4. Use constants in the body of your tests
If you must use constants, put them in a block at the top of your test file or a configuration file. There is nothing worse than having to search through all your source files because you changed a price from $199.95 to $199.99.
5. Create an internal-only API
Unless necessary for security or administration.
6. Create an internal only UI
You’re supposed to test what the customer will see after all.
7. Make your test too complex
No matter how brilliant your test is, keep it simple. Complexity just breaks later. If you are finding it hard to write, it will be hard to maintain too.
8. Test more than one thing
Stick to what you need to test. If you try to do too much in one test, it will just get more complex and more fragile.
9. Leave the test system in a bad/unknown state
This means a broken or unusable site, database or UI.
Comments