How to use Robotframework to write good test cases

Introduced

• This document will be a "high-level" principle of how to use Robotframework to write good test cases. The details of how to use robotframework to interact with your test system are not included in this document.
• The most important rule is to ensure that the test case is People who are familiar with this field are as simple as possible.
• For more information on this topic, you can check out these great resources below:
• Writing maintainable Automated Acceptance Tests Dale H. Emery
• How to Structure a scalable and maintainable acceptance Test Suite Andreas Ebbert-karroum

Naming a test suite

• The name of the kit should describe as much as possible the purpose of the kit.
• The name can be a bit longer, but it's a bit too long if it's more than 40 words.
• Remember that the Robotframework suite name is converted directly from the file/directory name. The suffix of the file is removed and the underscore is converted to a space, and if your words are lowercase, the initial letters are converted to uppercase. For example, Login_test.txt will be converted to login Tests, Dhcp_and_dns will be converted to DHCP and DNS.

Name of the test case

• The name of the test case should be similar to the name description of the package.
• If a suite contains many similar test cases, and the test suite itself is well-named, then the name of the use case can be shortened.
• The name in the test case file should exactly say what you need to do.

Keyword naming

• Similarly, the name of the keyword should be clear and specific.
• Should be able to express what this keyword has done, not how it is done.
• Keywords should be very different levels of abstraction (for example, "input character" or "user logged in to System").

Generation and decomposition of naming

• Try to describe what this step has done with a name.
• Maybe you can use a keyword that already exists.
• If the build or decomposition contains unrelated steps, you can accept a more abstract name.
• Listing the steps in the name is a recurring and maintenance problem (e.g. login system, add user, activate alarm and check balance).
• It may be necessary to use some generic names like "Initialize the system"
• Everyone who uses these test cases needs to understand what these build or explode actions are.

Documentation for the document test suite

• It is often a good idea to add a document to the lowest-level suite that contains the test case.
• High-level packages do not need to be documented so frequently.
• The documentation should contain the necessary background information, such as why to create these test cases, the points to be aware of in the test environment, and so on.
• The document content does not simply duplicate the name of the suite.
• If you don't have a document, you might as well not add it.
• The contents of the document do not contain too detailed information about the test case.
• The test case itself should be sufficiently clear and understandable.
• Repetitive information is a waste, and it is not easy to maintain.
• You can add some links to the details in the document.
• If you need to add a "name-value" group such as (version: 1.0 or Os:linux) to a document, consider using a test suite metadata

Documentation for test Cases

• Test cases typically do not require documentation.
• The package name and document and the name of the use case have provided sufficient background information.
• The structure of the test case should be that no documentation is required or that other comments are clear enough.
• Tags are usually more flexible than documents, and they provide more functionality.
• When the documentation for the test case is useful, don't worry about adding yo.

User-defined keyword document

• If the keyword is very simple and clear, no documentation is required.
• A good name and a clear structure are enough to explain everything.
• One important use of user-defined keyword documents is to record information about parameters and return values.
• The documents that are displayed in the RIDE (for example, where the keyword is complete) and in the resource file are generated by libdoc.py.

Structure of the test suite

• The use cases in the suite should be interrelated.
• If the test case has the same build or decomposition part, then they should belong to a suite.
• Unless it is data-driven, do not put more than 10 test cases in a suite.
• The test case should be independent.
• Initialize them with build and explode.
• Sometimes if the test cases are not related to each other
• For example, it may be because all the use cases are independent to take too much time to initialize.
• The associated test cases are just a few (up to 4 to 5)
• The next use case is used to validate the results of the previous use case. (with ${prev TEST STATUS} this variable)

Structure of test Cases

• The test case should be understandable.
• A test case tests only one thing.
• Of course, things can be big and small.
• Choose an appropriate level of abstraction.
• Consistent use of abstract levels (single-level abstract principles)
• Contains only information relevant to the test.
• Use cases can be divided into two types
• Test Cases for workflow
• Data-driven test cases

Test Cases for workflow

• Generally, the following sections are available:
• Preconditions (optional, usually in the build section)
• Action (perform some action on the system under test)
• Verify (there must be a validation section!) ）
• Cleanup (optional, usually in the decomposition section, to ensure that the use case has been completed)
• Keywords are used to describe what this use case does.
• Use a clear keyword name and an appropriate level of abstraction.
• Should contain enough information to enable manual execution to start.
• You should never need documentation or communication to tell you what this use case is doing.
• Different use cases can have different levels of abstraction.
• Detailed functional testing is more accurate.
• End-to-end testing can be a high level of abstraction.
• A test case should use only one level of abstraction.
• Different styles.
• More attention should be paid to technical details for the underlying detailed testing and integration test cases.
• "Executable definition" to play the demand.
• Use the language in the domain (terminology?) ）。
• Everyone (including the customer and the product owner) should be able to understand.
• No complicated logic.
• Do not use for loops or if/else to judge the structure.
• Be careful to assign values to variables.
• Test cases should not look as difficult to read as scripts.
• Up to 10 steps, the less the better.

Data-driven test cases

• Each test case has a high-level keyword.
• Different parameters are created for different tests.
• Keywords typically contain processes that are similar to the processes described in the workflow test cases in the same use case file.
• It is recommended to use the test template feature.
• There is no need to repeat the keywords multiple times.
• Testing in one use case makes it easier to test multiple changes.
• If possible, it is recommended to name the column header.
• If you really need a lot of test cases, consider making them dependent on the external model.

User Defined Keywords

• It should be easy to understand.
• The same criteria as the workflow test case.
• Different levels of abstraction.
• Can contain some programming logic (for loop, if judging these)
• Especially for the bottom of the keyword.
• Complex logic should be placed in the library rather than in user-defined keywords.

Variable

• Encapsulates a constant or complex value.
• Passing information from the command line.
• Pass information between keywords.

Name of the variable

• Clear, but not too long.
• It can be explained in the variable table with comments.
• Keep consistent with each usage scenario:
• The lowercase local variables are only available in the current use case or keyword.
• Global variables or suites, use case-level variables need to be capitalized.
• Spaces or underscores can be used to split the words in a variable.
• It is recommended to also list variables that are set as dynamic in the variable table.
• Use Set Global/Suite/Test variable keywords to name variables.
• The initial value of the variable should be able to explain what the actual value should be.

Passing and returning values

• The usual way is to return values by keyword, assign them to variables, and pass them to the parameters of other keywords.
• Follow this method clearly and easily.
• It looks like programming.
• The alternative is to use Set Test Variable keywords
• No programming style is required on the test case level.
• It's difficult to reuse keywords if you want to follow them more complex.
• Avoid this level of test cases below.

Avoid using sleeping

• The sleeping is very fragile.
• On average, safe boundary values can make sleeping a long time.
• Replace sleeping with keywords that contain a certain action trigger
• Wait for a value that needs to have a timeout.
• Keywords can be used Wait Until… to start
• If possible, use the built-in keywords Wait Until Keyword Succeeds to wrap other keywords.
• Sometimes sleeping is one of the simplest ways to solve a problem.
• Always use caution, not sleeping in custom keywords or other keywords that you use frequently.
• Sleeping is useful for pausing test execution when debugging.
• Although dialogslibrary is usually more suitable for doing this.

How to use Robotframework to write good test cases