TestProject Best Practices

I have written quite a bit about the TestProject framework, and my TestProject tutorial provides us the technical skills which we need when we write tests for our web applications.

This is a good start, but it's not enough. Before we can truly master a tool, we have to learn to use it in the correct way. That's why this blog post introduces five best practices which describe the best way to use the TestProject framework.

Let's begin.

1. Pay Extra Attention to Documentation

When we are writing tests or custom actions with the TestProject framework, we should document our code by following these rules:

• We should give proper names to our test classes. The name of a test class should identify the tested feature and the expected outcome. This is important because it helps us to find the correct file when we want to read the source code of a specific test case.
• We should specify the name and description of our test case by using the @Test annotation. Because the app.testproject.io website uses this information in its test reports, this approach helps us to locate the problem if a test case fails. If a test case fails, and it doesn’t follow this rule, we have to read its source code before we know what the problem is. This is a waste of time.
• We should specify the name of our action by using the @Action annotation because the name of our action is shown on the test results. If we use a human-friendly name, our test results are easier to read.
• If our test or action has input parameters, we should provide a good description to every input parameter. This makes our life easier when run our tests on the app.testproject.io website because these description are shown on the view that allows us to override the default parameter values of our input parameters.

2. Elimate Duplicate Code by Writing Custom Actions

When we write tests with the TestProject framework, the odds are that we identify duplicate code which is required by multiple test classes. We can solve this problem by writing a custom action which provides the required functionality to our test classes. After we have written this action, we can remove the duplicate code from test classes.

The TestProject framework supports two different action types:

• A web action is a good choice if we have to access the entire DOM.
• A web element action is a good choice when we have to write tests for a web application that has components which are shared by multiple views. Web element actions save us a lot of time when we are dealing with complex UIs because the TestProject framework locates the required components for us and the web element actions allow us to interact with the found components. In other words, we can write (or record) our tests without digging into the complex DOM.

3. Write Automated Tests for Custom TestProject Actions

Because custom TestProject actions are basically libraries which provide features to our test cases, we should ensure that these features are working as expected. We could test our actions manually, but the problem is that we would have to do this every time when we make changes to our actions. This is a waste of time.

That's why I think that we should write automated tests for our TestProject action with JUnit. These tests helps us to save time when we have to verify that our actions are working as expected because our computer does all the hard work for us.

4. Leverage the Logging Capabilities of the TestProject Framework

The TestProject framework provides tools which allow us to report the progress of our test cases and actions. We should leverage these tools when we write tests or actions with TestProject framework because comprehensive logging helps us to debug failing test cases.

When we use these tools, we should follow these rules:

• If our test case has multiple steps, we should identify the different steps by sending a log message to the TestProject framework. This helps us to identify the step which failed our test.
• We should report the exact reason why our test either passed or failed. This makes our life a lot easier when a test case fails because we know exactly why it failed.
• A custom action should report the errors which occurred when it was run. These error messages are useful when we have to debug failing test cases.
• If a custom action extracts information from the rendered HTML document, it should report the extracted information. This helps us to debug failing test cases.

5. Follow Selenium Best Practices

Because the TestProject SDK uses Selenium WebDriver, we should follow Selenium best practices.

Summary

This blog post has taught five things:

• We should document our tests and actions by using TestProject annotations because these annotations make our life easier when we run our tests on the app.testproject.io website.
• We should eliminate duplicate code from our test suites by writing custom actions which provide the required functionality to our test classes.
• We should write automated tests for our TestProject actions because these tests save us a lot of time when we have to ensure that our custom actions are working as expected.
• We should leverage the logging tools provided by the TestProject framework when we write tests or actions because comprehensive logging helps us to debug failing test cases.
• Because the TestProject SDK uses Selenium WebDriver, we should follow Selenium best practices.