Test Automation 101: (4) Applying a Project Structure
If you have successfully followed my previous tutorials, then we now have automated tests using Robot Framework. But that’s not enough. The real challenge is this:
How are you going to structure your Test Automation Project?
There’s no one-size-fits-all solution. There are different approaches. So, the sample project structure I will show here is just one way to do it, not the rule or the standard. I will provide a starting point since I made this tutorial series for beginners. So, let’s get to it.
The image below is the piece of code we have so far.
In one robot file, we have the following sections:
- Settings — contains the imported libraries.
- Variables — these refer to the element locators.
- Test Cases — the set of test cases with different data inputs.
- Keywords — keywords that contain a series of actions that you can reuse.
In an extensive application, there will be many more libraries to import, element locators to capture, test cases with different goals, and keywords. It can’t be all contained in just one file. One way to organize it is to have two main folders: resources and test cases.
Resources — will contain the element locators (we’ll call them objectmaps) and the keywords. These will be grouped by module/functionality/page, whichever makes sense in the specific application.
Another folder called “common” will contain the common “objectmaps” and keywords. The definition of “common” is a module/functionality/page with which many test cases will have to interact, such as the login page. In most applications, there will be a login page. Thus, tests will always have to interact with it.
Test Cases — will contain the set of tests grouped by suites, followed by module/functionality/page. Suites refer to the kind of test you want to do. Is it a quick run to see if the application is usable for further testing, like a Smoke Test? Or an end-to-end functionality test? Or other kinds of testing you want to do in your organization? Once you know what testing you want to do, group them by type.
Let’s apply the grouping described above to our original code to understand it better. Here’s what the folder structure would look like.
And here are the contents of the files.
objectmaps_loginpage.robot
keywords_loginpage.robot
login.robot
Things to note:
- In keywords_loginpage.robot, the “Settings” section should be present. Notice that it also imports the objectmaps resource file.
- In login.robot, the “Settings” section only imports the keywords resource file since you already imported the libraries and objectmaps. In other words, resources are nested.
If you want to copy and paste the code, they are stored here -> vncrtech/test-automation-101-rf (github.com)
You can further extend this suggested folder structure. In the “common” folder, there could be an application settings page, a static data page, a logout page, etc.
For the modules, there could be a payment form, transaction history page, etc.
The suggested folder structure makes it easier to manage since the resources are all in one place. Suites also group the test cases so that you can run only a specific group.
The goal of establishing a project structure is for the team to efficiently manage the main parts of their test automation project — the resources and the test cases — and to make it intuitive and user-friendly. Again, different approaches are available; I showed just one example here.
In the following tutorial, we will push all our code so far to GitHub.
