Best practices for modules

Modules contain all the technical information that Tosca Cloud needs to navigate and interact with your application. You create modules by scanning and then use them to design a test case.

This topic is all about best practices for modules: how to structure them, name them, and arrange them. It helps you to create modules that are intuitive to use, so you can quickly grab the right one for what you're trying to do.

Module purpose

When you scan your application to create a module, you might be tempted to keep things simple: create one module per screen. However, this approach isn't suitable for all screens.

Most applications have many, many controls per screen: menus, sidebars, footers, text boxes, links, buttons, and so on. And typically, users don't have to go through all of them every time.

To use modules to your best advantage and keep your maintenance effort down, we strongly recommend the following:

  • DO split the module according to screen areas or requirements, rather than by "all controls for user workflow A", "all controls for user workflow B", and so on. This gives you the flexibility to mix and match modules and reuse them to test different workflows.

  • DON'T create modules with overlap, which are multiple modules that include the same controls. For example, "Module A for user workflow A, which requires controls 1, 2, 3, 4, and 5" and "Module B for user workflow B, which requires controls 1, 2, 3, 6, and 7". Duplicate modules duplicate your maintenance effort if your application changes.

  • DO keep a maximum of 20 controls per Module. This keeps modules easy to understand at a glance and to use.

  • DON'T create mini modules with just one or two controls. A large number of mini modules complicates your maintenance. As your application changes, it'll be increasingly hard to keep an overview of what you have, what you need, and what goes together.

Let's take a look at the Demo Web Shop screen. Here, you should create separate modules for each: header, footer, ribbon menu, categories, manufacturers, popular tags, featured products, and so on.

Screen elements in the Demo Web Shop

This lets you mix your modules to test any possible flow on this screen, without creating extra maintenance due to overlap between modules.

Module names

By default, Tosca Cloud uses a window's caption as the name of the module. In some cases, this might be impractical, and you need to rename your module.

For example, you need to rename your modules if the caption is always the application's name, no matter which screen you are on. If you don't, you'll end up with confusing search results and have to spend extra time figuring out which one is the module you need.

Avoid this! Multiple modules with the same name make it hard to find the right one.

Always make sure to use descriptive module names, so your fellow testers can find the right building blocks quickly and easily. We recommend this basic naming convention:

<application name, abbreviation> | <general section that the module's controls are in> | <what the module covers>

Module attribute names

A module attribute is the technical representation of a single control.

By default, Tosca Cloud uses a control's label as the name of the module attribute. If your application doesn't provide good labels, you need to rename the module attributes. If you don't, your fellow testers won't know what to do with the module:

Avoid this! Bad module attribute names make this module pretty much unusable.

Always make sure that your module attribute have simple, human-readable labels that explain the meaning of the control. That way, your testers can quickly identify screen elements and define the right test actions for them.

Yes! Good module attribute names make this module intuitive to use.

Order of Module attributes

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

So, if the order of the module attributes after the scan is not the same order that you need in your tests, change the order in the module. Otherwise, you have to rearrange your test steps every time you use the module in a test case.