Photo by Alex wong on Unsplash

Test Automation 101: (5)Project Structure Sample

*Please read the tutorial introduction, in case you haven’t yet. Here’s the link -> [LINK]

*Previous article in the tutorial series -> [LINK]

If you have successfully followed my previous tutorials, then we now have an automated test using Robot Framework which is connected to a remote repository. 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’m about to show here is just one way to do it, not the rule or the standard. Since this tutorial series is intended for beginners, I am going to provide a starting point. So let’s get to it.

This is the piece of code we have so far.

In one robot file, we have the following sections:

  1. Settings — contains the imported libraries.
  2. Variables — these are the reference to the element locators.
  3. Test Cases — the set of test cases with different data inputs.
  4. Keywords — the keywords which contain a series of actions that can be reused.

In a big application, there will be a lot 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. So one way to organize it is by having 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 which many test cases will have to interact with. For example, 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 then module/functionality/page. Suites refer to the kind of test being done. Is it a smoke test, a quick run just to see if the application is usable for further testing? Or an end-to-end functionality test? Or other kinds of testing that is being done in your organization.

To understand it better, let’s apply the grouping described above to our original code. Here’s how the folder structure would look like.

And here are the contents of the files.




Things to note:

  • In keywords_LoginPage.robot, the “Settings” section should be present. Notice also that it imports the objectmaps resource file.
  • In LoginPage.robot, the “Settings” section only imports the keywords resource file since the libraries and objectmaps were already imported there. In other words, resources are nested.

(If you want to copy and paste the code, they are stored here ->

The folders above can be further extended. In the common folder, there could be application settings, logout page, etc.

For the modules, there could be a payment form, transaction history page, etc.

With the suggested folder structure, it is easier to manage since the resources are all in one place. The test cases are also grouped by suites so you can run whichever is necessary at a particular time.

In the end, I think the goal of establishing a project structure is for the team to be able to easily manage the main components of their test automation project — the resources and the test cases — and to make it intuitive and user-friendly. Again, various approaches to this can be applied and what I showed here is just one example.

In the next tutorial we will configure Jenkins to run our automated test cases.

*If you ran into some issues, I’d be happy to assist. Just leave a comment and I’ll respond as soon as I can.


  1. Workspace Setup Guide — Simple and Easy
  2. Capturing HTML elements on the Web page
  3. Creating Keywords and Tests in Robot Framework
  4. Robot Framework Project and GitHub integration
  5. Project Structure Sample
  6. Robot Framework and Jenkins Integration <<< === HERE!!!




Just someone who dreams of changing the world.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

What happens when you build a bot in 5 minutes?

Why You Need Cloud Managed Service Provider?

Harnessing the Power of Hackathons

The Tenets and Benefits of Object Orientated Programming

A diagram showing the characteristics of OOP.

PPL 2020 — Unit

Striving for iOS App Performance

Setting up the local Hyperledger Composer

Video Clip Organizer Software Mac

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Vince Reyes

Vince Reyes

Just someone who dreams of changing the world.

More from Medium

DevOps Working Model for Continuous Testing (CT) With Katalon

How To Implement Shift Left Testing Approach

Telemetry and Application Insights in Testing.

Three Different Ways on Cucumber Runner