Is it a good/industry practice to create both UI and API testing projects in one project?

Question

I'm planning on creating a project to begin test automation for software. For this task, I'm considering the following things:

1. UI level testing (with Page Object Model)
2. API testing
3. Database testing

So, my question is, is it good practice to create all three in the same project or should I create three separate projects? Or is there any other better solution?
How do other companies do this?

Answer 1

I think approach depends heavily on several factors:

1. Will languages/technologies used for API, UI and DB testing be the same?

If yes, I prefer creating one project with API, UI and DB clients. In that case, you will be able to use API methods (that are usually faster, than UI ones) to place the system under test in a specific state and only after that use UI client to check UI part. Also, it allows not only to test database by itself but also use DB client to validate that changes made in UI/API are properly propagated to database. So, end-to-end scenarios can be covered better using this approach.

However, if it is better to test UI using special tools (in case of JS or Spring-based UI) that are not supported by your language of choice for backend testing, it might be beneficial to separate repositories for frontend and backend testing.

2. Will testing methodologies applied to frontend and backend testing be the same?

For instance, if you would like to use Behavior Driven Testing (BDT) for frontend, you might want to separate UI and API testing repositories in order not to think about wrappers for running different tests and make the test code more readable by not mixing the paradigms.

Answer 2

Both approaches have advantages and disadvantages:

Separation into multiple projects means better separation of concerns. You can build your framework in a modular fashion like this. Where shared libraries are pushed up to some versioning tool like Artifactory and imported into each of the individual projects. But you will also more time managing configuration, versioning and dependencies.

I prefer having one repository with multiple projects within different directories. Sometimes referred to as "mono-repo." Mono-repos make it easier to share code because utility libraries written for one portion of the project can be used by other portions of the project. (They are just in different directories) Also has easier git complexity. There is also less throw it over the wall mentality. If you are modifying a shared library and break other frameworks, your unit and integration tests should fail. You also have easier on-boarding because new team members only have to be concerned about one repository rather than download multiple ones.

There are also some scaling issues with mono-repos but most projects will never get to that scale.

Google On Mono-Repos

Answer 3

Let me show you our structure and its advantages.

Preliminary note: our test frameworks are available as NuGet packages which are used in actual project repositories such as the one below.

Repository

• Solution A (backend code)
  • Any number of projects here
  • Unit testing (written by developers also)
• Solution B (testing code)
  • API testing project
  • UI testing project

Advantages:

• Test and backend code can be branched and versioned together
• Setting up build definitions for a separate project and/or solution is easy this way - you'll have reduced build times and avoid unnecessary builds (no need for a backend build if only test code was changed).
• If a single repository/project needs a package update (to test new features not available elsewhere) you can do this as every test project is isolated within its own repository.

Answer 4

I prefer to segregate the projects. There are few pros for doing so:

• If there is quite a lot of code in your project then you'll have to wait while all your code will get consistent (compiled, addressed all the dependencies, generate auto-generated code, etc) on each run
• You might need to maintain stubs for the parts of the code that is not relevant to your domain (for example you might have auto-generated classes for your API project part and those who develop UI tests might not have the access to URL holding WSDL for example)
• The more code you have the more chances that you might go in a conflict in terms of code housekeeping and versioning (at least you will share common project meta-information)
• Some parts might have missing defects in the area that is not your domain currently and you'll have to deal with them having no enough skills (for example your project might fail build phase because of lack of code review or unit testing)
• Using different projects will let you use different implementations of particular concepts in more error-prone way. For example some like using TestNg and some like using JUnit. They both have @Test annotation or so. So you will have less chance to confuse something if you use a separate project for UI rather than those responsible for API.