Best practices | Modules | Order of ModuleAttributes

A ModuleAttribute is a child element of a particular Module. It's the technical representation of a single screen element in your application under test: a button, a field, a table cell, a menu, and so on.

When you scan your application to create a Module, Tosca saves the ModuleAttributes in a specific order. This order is determined by the hierarchy of the controls in your application code. And at runtime, Tosca processes from top to bottom.

This may not work well for all TestCases. For example, let's take a look at this user interface:

Controls in a login screen

Users have to enter their credentials, select Remember Me if they want to, and then select Log In. Selecting Log In takes users to a different screen.

However, because of the way the controls show up in the code, the resulting Module looks like this: 

Controls in the Module after the scan

If you want to test the entire sequence, including Remember Me, this will cause problems.

At runtime, Tosca selects the Remember Me checkbox as the last step in your test sequence. This step will fail, because the previous Log In step takes users to a different screen where Remember Me doesn't exist.

There are different solutions: 

  • Option 1: create two consecutive TestCases from the same Module. The first TestCase enters the credentials and selects Remember me. The second TestCase selects Log In.

  • Option 2: rearrange your ModuleAttributes via drag and drop before you start creating TestCases.

In this particular example, option 2 is clearly the way to go. There's only one viable test sequence.

Controls in the Module: now in the right sequence

It's a little trickier with interfaces that have multiple viable sequences. We recommend that you carefully weigh the level of effort. How much extra work do you expect if you choose option 1, and how much work for option 2?

What not to do

You might be thinking, "What about option 3? Just copy and paste the Module and delete the Remember Me ModuleAttribute from one of them."

We strongly advise against this option. This duplicate Module doubles your maintenance effort if something changes in any of the other controls of the login screen. As a general rule, you want to avoid having multiple Modules for the same screen elements.

What's next

If you haven't yet, check out our other best practices articles.