8

It depends. Right now you might not see much need for a single repository design. Later, you may find your opinion changes. You might want to use a single repository if you need to keep your different projects in sync. It's more difficult to keep separate repositories in sync than a single repository. your team members will need to switch between ...


6

Generally as code bases grow you should divide up code into small individual chunks. For example with application code you could have all the classes and methods in one file - say 12,500 lines long. However that becomes impractical and unweildy to edit. It's better to break code up into individual classes and put each in a separate file. The same ...


5

Definitely, not in a single file. It does not scale. Putting tests into a single growing file hurts readability, becomes inconvenient to navigate through and prevents you you from seeing a bigger picture. Remember that the Code is much more often read than written. We are using Protractor as well and have a large test codebase and I think, we've learned a ...


4

Running all tests at once is something that a Continuous Integration server should do for you, not something you do manual as it lets you wait for a long time. Let a server do the work and reporting. Multiple repo's have the following advantages: Easier to schedule parallel-runs in a CI. Will be faster. (technically also possible with a single repo, but ...


4

Adding to the awesome and very detailed existing answers. There is a well-known success story of using a single large repository - Facebook and Google. As of 2014, Facebook's main repository was 54 GB in size. As of 2016, Google's main repository had 35 millions commits. One of the most important advantages of having a single repo is atomic commits across ...


3

In essence, it doesn't change much, after all... “Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.” James Bach, Exploratory Testing 3.0 Therefore, the idea behind testing architectures ...


3

For the test infrastructure code (helper and utility classes, custom logic, etc) - unit testing might make sense in case if you are providing your framework to a 3rd party usage (that can be a community in case of opensource or even the other team within your organization). Approach it as a regular code and follow the common unit testing approaches. For the ...


2

If you are deciding to use better reusability in selenium-python, following are my experience based recommendations which are touch based with ISTQB Test Automation Best Practices: How to structure or architect a test project with Python? Better to follow generic Test Automation Architecture while building the repository: https://engineers-hub.teachable.com/...


2

Setting aside opinions people may have about SAFe and how Agile it really is, there is no conflict between SAFe as it is defined and TDD or BDD. In fact, the official safe write-up for teams suggests that software teams should be using those practices (https://www.scaledagileframework.com/agile-teams/). SAFe also still prescribes cross-functional dedicated ...


2

Generally speaking, it depends on the application For a very simple application where you're only automating a single type of tests, dividing things up into multiple files adds very little value. For a complex application with multiple segments, where you're automating several different types of tests, it's clearly a good idea to separate things into a ...


2

I would apply KISS and YAGNI principle: Keep It Simple, and You Ain't Gonna Need It. Start with one, and split into separate repositories when you can see the business need for it, and benefits. I agree with @KatePaulk with pros and cons, but when no obvious benefits, I would go with simpler solution: single repository.


1

Split the tests by feature It will definitely help to split the tests up into "suites" which test features or functionality that fit together in human usage flow (eg 'login' might test the login page display, authentication, OAuth2 etc. but is really just all under login). Use a test runner If your testing framework doesn't allow you to do this (it does) ...


1

The way that I've organized automated test solutions is... 1 Project per application, 1 Folder per major area of the application, 1 TestClass file per screen. Depending on the granularity of your application and amount of tests you could write for it, you might need nested levels of folders that properly reflect the product's granularity. I.e. if an ...


1

Is this for web testing? If so, you can use Kantu. Essentially it is the same as Sikuli, but runs inside the web browser. So you can run many instances at once and in the background. Also, the system can be locked while the test are running.


Only top voted, non community-wiki answers of a minimum length are eligible