6

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?

4 Answers 4

2

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.

6
  • "Will languages/technologies used for API, UI and DB testing be the same?" What if the answer is no? I'm planning on using Jasmine on E2E and rest assured for api. In that case how can I do this task?
    – Syrus
    Apr 29, 2019 at 4:52
  • 1
    @Joe On my projects, I usually separate test automation repositories based on the application tested (obviously) and language used. So, in your case, if the main language you are planning to use for E2E and API testing is JavaScript, I would create 1 project with 2 clients (UI and API) and 2 sets of tests. In that case, it might be more convenient to make some of the preparation steps for UI end-to-end tests via API and reuse your API client there.
    – Harby
    Apr 30, 2019 at 4:44
  • I'm going to use java for API and javascript for E2E since our front end has created using Angular. As I mentioned in the question, I have to use DB testing too. I don't know to attach these db tests with E2E and API projects or clients. Since my technologies are gonna be different I guess I'm gonna have to create 2 projects instead of 2 clients in one project. Really appreciate if you could give me little example on this matter?
    – Syrus
    Apr 30, 2019 at 5:05
  • 1
    I had only one project with a similar structure: JS for UI and Python for backend and database testing. In that particular case, I created 2 repositories: all UI tests + lightweight API client were written in JS, whereas all backend (application API/DB + integration with other projects) tasks have been covered with Python tests. Not sure if it might be an example of good practice since there was some overlapping in functionality between "heavy" Python API client and a "light" JS API client required for UI testing, but it was faster to port some API methods in JS, than to call Python code.
    – Harby
    Apr 30, 2019 at 7:35
  • 1
    Well, here I am using "Project" to describe a piece of work that needs to be done: to cover frontend and backend of an application under test with a comprehensive set of tests. This task is accomplished with code stored in 2 separate GIT repositories: one for UI and another one for API/DB tests. Corresponding tests are even run separately by 2 different Jenkins jobs.
    – Harby
    Apr 30, 2019 at 17:31
5

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

2
  • "Also has easier git complexity" Until you need to review the commit history... Oct 23, 2018 at 19:18
  • It really has no effect on the comment quality. More of the git workflow and branching strategy.
    – newsn31
    Oct 24, 2018 at 20:32
2

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.
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.