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

Clash Royale CLAN TAG#URR8PPP

up vote
1
down vote

favorite

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?

automated-testing api-testing uiautomation

share|improve this question

edited 1 hour ago

trashpanda

1,1631525

asked 2 hours ago

Joe

3621313

add a comment | 

up vote
1
down vote

favorite

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?

automated-testing api-testing uiautomation

share|improve this question

edited 1 hour ago

trashpanda

1,1631525

asked 2 hours ago

Joe

3621313

add a comment | 

up vote
1
down vote

favorite

up vote
1
down vote

favorite

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?

automated-testing api-testing uiautomation

share|improve this question

edited 1 hour ago

trashpanda

1,1631525

asked 2 hours ago

Joe

3621313

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?

automated-testing api-testing uiautomation

automated-testing api-testing uiautomation

share|improve this question

edited 1 hour ago

trashpanda

1,1631525

asked 2 hours ago

Joe

3621313

share|improve this question

edited 1 hour ago

trashpanda

1,1631525

asked 2 hours ago

Joe

3621313

share|improve this question

share|improve this question

edited 1 hour ago

trashpanda

1,1631525

edited 1 hour ago

trashpanda

1,1631525

edited 1 hour ago

trashpanda

1,1631525

1,1631525

asked 2 hours ago

Joe

3621313

asked 2 hours ago

Joe

3621313

asked 2 hours ago

Joe

3621313

3621313

add a comment | 

add a comment | 

1 Answer
1

active

oldest

votes

up vote
2
down vote

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

share|improve this answer

answered 1 hour ago

newsn31

3312

add a comment | 

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "244"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsqa.stackexchange.com%2fquestions%2f36136%2fis-it-a-good-industry-practice-to-create-both-ui-and-api-testing-projects-in-one%23new-answer', 'question_page');

);

Post as a guest

Name Email

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
2
down vote

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

share|improve this answer

answered 1 hour ago

newsn31

3312

add a comment | 

up vote
2
down vote

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

share|improve this answer

answered 1 hour ago

newsn31

3312

add a comment | 

up vote
2
down vote

up vote
2
down vote

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

share|improve this answer

answered 1 hour ago

newsn31

3312

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

share|improve this answer

answered 1 hour ago

newsn31

3312

share|improve this answer

share|improve this answer

answered 1 hour ago

newsn31

3312

answered 1 hour ago

newsn31

3312

answered 1 hour ago

newsn31

3312

3312

add a comment | 

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsqa.stackexchange.com%2fquestions%2f36136%2fis-it-a-good-industry-practice-to-create-both-ui-and-api-testing-projects-in-one%23new-answer', 'question_page');

);

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email