It is open source tool, anyone can download & use
It supports various operating environments (Windows, Linux, Mac etc...)
It supports various programming languages to create and execute Tests
It supports all popular web browsers
It supports parallel test execution
It uses less Hardware resources as compare to other popular tools like ...QTP/UFT
Open source, active contributions 24/7
Wide range of supported languages
Lots of online resources
Good multi browser support / Parallel testing
Excellent for what it does (when you learn to implement it properly to prevent flaky/brittle tests)
Easy integration with the likes of Maven/TestNG/Jenkins etc
Multi OS support
Lightweight in terms of ...
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 ...
If the Java GUI application is based on Swing, AssertJ Swing is probably one of the best open source libraries. It's a fork of FEST and has several advantages:
Simulation of user interaction with a GUI (e.g. drag 'n drop)
Reliable GUI component lookup (by type, by name or custom search criteria)
Support for all Swing components included in the JDK
When you set out to solve as general a problem as "something that can be used to test just anything", the programming language you use to code the framework is less important than the abstractions you support. That is where I would start.
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 ...
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.
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 ...
I know about several open source tools hosted on GitHub but didn't try them yet. Just created a list for future learning. Any additions and comments are welcome.
TestFX - 213*
Automation (Groovy & Java) - 48*
swinger (JRuby, Cucumber-based) - 47*
Marathon - 31*
Window Tester - 5*
This list might be updated in the future. I'm maintaining it at the ...
You are doing something very weird. JMeter threads are totally independent and each thread has its own context, variables, cookies, etc.
If you have 1 thread - it will execute 8 requests in sequential order (upside down)
If you have 2 threads - each of 2 threads will execute 8 requests in sequential order
So I would recommend removing your ...
Pros: you can start writing cross-browser code in your favorite programming language in a matter of hours
Selenium tests are unstable.
WebDriver libraries version trail the auto-updating browser and there’s always something small that doesn’t quite work. Often when you get the new version of the Selenium libraries that is supposed to fix the issue, ...
Normally what you call a Test Runner is a part of testing framework that is responsible to define which code of yours can be considered a test code and that is responsible to execute the test code. Test runner does not make sense with no respect to test framework as well as vise versa.
You've correctly spotted the problematic use of dynamic ids, that makes it hard(er) to write and maintain tests with Selenium.
I'm not entirely sure, but it should be possible for the developers to add (unique) names to each widget, making stuff easier to find.
Regarding your question, 'what are the tools', I suggest you take a look at Sencha's own testing ...
From the comment to answers, @Crustyeyelids, there is a big misunderstanding. There is a big difference between:
"Selenium IDE" (small part of the Selenium project) and
Selenium project with all the components: Grid, Webdriver, Selenium Server (and IDE).
Selenium IDE is almost useless, for real production tests.
Selenium (project) is W3C standard for ...