What are test environments

The test environments, or test environments, are used to test our products and services. features independently from the other teams. This is useful when, in a company, several teams need to use applications for testing and introduce code modifications to test their developments. If each team has its own test environment, this avoids situations where one team's development breaks the part that another team needs to make it work.

The idea is that these test environments replicate our productive environment although it does not have to completely fulfill all the cases. We may have some external dependency that, for testing purposes, we need to always return the same response to move forward with our tests. In that case, we can mockear type of service or dependency.

The main benefit of having test environments is to be able to test the development of a feature and host documentation about these tests in our task management platform or the one used by our QA department for testing.

What should a test environment be like?

Independent

As we have indicated above, a test environment must be independent from the rest in order to ensure proper operation to the computer that is using it. This means that each team can have a version of an application for its use without other teams adding modifications affecting the expected behavior of the application. In addition, when it comes to deploying changes, each team is autonomous and does not need to wait for another team to upload some functionality, fix or terminate the previous deployment to avoid problems.

Easy to create and destroy

Perhaps a dilemma for some companies when managing new test environments is, what do we do with the bill? The increase may not pay off. The idea is that these test environments are easy to create and destroy, with the purpose of creating them early each day and destroying them once the day is over.

Maintaining the state is important

When we say maintain the status we mean that when our test environment is destroyed and recreated, the database remains as it was before the environment was shut down. This can be done through a backup policy. Tools such as Terraform (or any IaC, or Infrastructure as Code) allow us to adjust our policy in this regard.

It is also important for the management of feature flags, Sometimes we must have that flag active for a certain time to see that everything works correctly, so if we save the feature flags outside the database we have to provide another backup policy for this.

Why test your development

The main purpose of testing what we develop is to make sure that it works and that it does not break anything that already existed before. When we talk about testing, we include all kinds of tests, such as those that the developer himself can do while developing: unit tests, integration tests and e2e (end-to-end tests). Once these tests pass in green (we can use TDD, BDD or whatever we find most appropriate), it is time to test our feature in the environment we have prepared for us, collect evidence and be able to pass the task to QA to take a closer look or, at least, to test from another perspective.

Testing also helps us to align with product requirements. DoD's (definition of done) help us, with a few simple lines, to be clear about what the application should do after applying our changes. And these DoD's must be tested in our tests to be able to give evidence of them and to be able to complete the task and deploy in real production environments.

An advantage of having these evidences is that if we have any mishap in production, we can quickly check what we have tested and in what way to try to recognize what is happening in production environment. By having the tests saved, we could rule out that the failure is due to one of those flows that are justified. When we fix the failure, we must provide new tests to check that it has been fixed in the right way without messing up anything that was already there.

Tips for testing well

Learning to test is one of those soft skills that we must develop throughout our life as programmers. At the beginning we are more confident with ourselves but as you gain experience you internalize that testing is not superfluous and that it is always good to add new ones. So, here are some tips that may be useful:

• As we have mentioned before, it is essential that we leave evidence of our tests. Sooner or later we will have to review some user story tests and, if they have not been performed, we are going to be angry with our past selves.
• Even if we have a QA person in our team, let's make his job a little easier. Our development tests should be exhaustive (as much as possible) because this way we can be much more confident with our developments when we see that they are deployed without problems, and we save time to our QA colleagues.
• It helps a lot to approach the stories under TDD or BDD because we are not coupling our tests to the code, but we think about how it should behave and then we have more flexibility to be able to introduce the code and, if necessary, to refactor.
• Take your time to test. Remember that the time you spend testing is not time wasted, it is time you avoid fixing something that is broken.

Looking for more tips and tricks to help improve your development? Find here more posts from our fantastic devs and Secture & Code contributors.