When you first start out with Squish, structuring and organizing your tests and executions can be a daunting task. Here, we outline a few pointers to help you avoid unnecessary work and ease you into creating a robust and maintainable testing framework!
How Squish Structures Its Tests
If you’ve completed any of the introductory user tutorials (like this one for Qt), you’re probably already familiar with the following. At the top of your folder hierarchy, there’s a Squish test suite folder which essentially contains:
- A suite configuration file.
- Named test case folders each containing a test script or Behavior-Driven Development (BDD) test.
- A shared scripts folder containing a (scripted) object map for identifying UI elements.
The object property names recorded in the object map can be used across all test cases of a suite, so it is a good idea to group test cases using the same UI into a suite.
Follow the DRY Principle (Don’t Repeat Yourself)
Be it part of a script automating UI interaction or an object name: if parts of your script or an object name are used more than once, it’s a good idea to write them down only once and reference them where they are needed. Here are a few ways you can achieve that:
- Use BDD tests (see Qt BDD tutorial). BDD tests contain steps, each representing a specific interaction with your UI, and they can be used many times throughout your BDD scenarios. Naming a step helps you think about the goal of that snippet of test code. Something like, “I log in as a user” makes it clear what it does, and is likely to be used in multiple scenarios.
- You can also create shared scripts for your test suites, allowing you to share functionality across all of the test cases in that suite.
- If you need to share scripts across multiple suites, use global script directories. From version 6.4 on, this advice also applies to object maps, as Squish treats them as scripts.
If something needs changing later on, you know where to make your edits, and you only need to do it once.
Clean Up Your Object Names
If the guidelines above create organized test suites, refactoring object maps is what keeps them organized:
- Avoid the occurrence property. Squish falls back on this only if it can’t find any other property to identify an object uniquely. This becomes problematic if other UI elements are added later on and change the order of occurrences.
- Account for volatile properties. Some properties might change during execution (an example being the text on labels.) You can either remove properties, or use wildcards or regular expressions. When removing properties from an object name, make sure that it still uniquely identifies an object. Take a look at the documentation for a good overview on how to improve object identification.
- If you are already familiar with how object names work and want more control over how they are created, take a look at the object descriptor files. These give more control over which properties Squish uses to generate object names during recording.
Using Tags
Using BDD and running tests on multiple configurations (differing Operating Systems, AUT versions, etc?) Make use of tags! For example, some of your BDD scenarios may not be applicable to a certain configuration. Tagging these (e.g. @foo) allows you to tell squishrunner to exclude them (using our example: --tags ~foo).
Check out a past blog on this topic: How to execute only desired BDD scenarios. And read more about tags in our documentation: Playback option –tags.
Avoid Hidden Dependencies Between Test Cases
The test cases of a suite are executed in order of creation. (You can change that order via drag & drop in the IDE or by editing the TEST_CASES field of the suite configuration file suite.conf.) Sometimes hidden dependencies between your test cases can start to creep in (i.e. case A performs actions on which case B unknowingly relies later on). Randomizing the execution order of tests makes it easier to spot these dependencies. You can randomize execution order of tests (using the –random squishrunner option).
Keep It Simple!
Only write test code when you are sure it will be used! For most test environments, Squish’s test suite architecture and execution modes will be sufficient. Additionally, if you are looking for a feature, check the documentation and Knowledge Base first. Squish might already provide what you’re looking for, saving you the effort of building it yourself.
The post Tips for Structuring Your Squish Tests appeared first on froglogic.