A critical factor in building a automated test suite with a low maintenance cost is eliminating duplication of data. One way that MuseIDE supports this goal is with the use of Variable Lists and Context Initializers as described in this section.
In the previous section, I showed how to parameterize a test for the purpose of running slight variations on the same test. In this section, I will parameterize more parts of the test, but with the purpose of reducing duplication of data between multiple tests in a project.
The first test I created has 3 parameters in the first two steps. It is very likely that I will repeat these parameters in the next test I create. That creates data duplication, and a maintenance headache, so I want to fix that.

Replace with variable references
As in the previous section, I start by replacing these with variable references.

Create Variable List
Next, create a Variable List in the project. I will use this for parameters that will be provided to every test in my project, so I call it project-vars. Then add a variable for each that we defined in the test.

Create Context Initializer
Finally, I create a Context Initializer to inject these variables into every test.
A Context Initializer can inject variables into the test execution context before the test starts. They execute before the Test Variables are injected. You can override variables injected by a Context Initializer in any test by defining a Test Variable with the same name. This can be useful for debugging a test, or making specific tests use a different value.

A Context Initializer is the third method of injecting variables into the test execution context before it starts (the other two are default test variables and parameterized test suite).
The first configuration option for the initializer is the id of the list of project variables to inject. The second is a condition that will be evaluated - if it evaluates to true, then this initializer will inject the variables (otherwise, it does nothing). I want the project-vars list injected into every test, so I simply set the condition to true.
If I use this technique for every test in my project, then I can easily change which browser the tests use (or the browser provider or the starting URL) in just one place.
Note: An initializer can do much more sophisticated work than shown in this example, by referencing System Variables. For example, it could inject a different list depending on which environment the test is running in. This would allow it to use one starting URL when running on your CI server, while using another starting URL when running on your desktop.
Next: Minimizing logic duplication.
Return to Tutorials page