Reputation: 41
This topic is the beginning of the answer I am looking for. I need to know more.
Why use GRID if pure TestNG parallel execution seems to work just fine?
Background:
Question:
My own thoughts: The only thing i can think of to justify GRID is running the tests using different machines. If we would need to actually balance the load on several servers. But at this point even my own laptop is doing the job just perfectly. This situation will not change dramatically in nearest future, so why bother? The link mentioned above claims the results of the no-grid parallel tests may become unpredictable. We do not face that. So the question may be: in what sense unpredictable? What to watch out for?
Thanks in advance for your help.
cheers, Greg
Upvotes: 3
Views: 4163
Reputation: 298
Lets consider some examples:
Your target is to check functionality on windows as well as on MAC. Without grid you will run the cases twice.
You got a test case where a functionality breaks at older version of a browser and now its time for regression test. Without grid you will be running test cases multiple times for each browser's older version.
A case that is dependent on different screen resolutions.
Grid can simplify the effort for configuration.
Its just about making the time as much minimal as possible for running number of test cases.
Upvotes: 1
Reputation: 1804
The Grid mimics as a load balancer and distribute tests to nodes according to the desired capabilities. While the parallel attribute in testNG xml is just instructing the testNGrunner to trigger n number of tests at one go.
CAVEAT : If you do not use grid for parallel test execution, your single host will get overloaded as you scale up the thread-count. The results of the no-grid parallel tests may become unpredictable because multiple sessions will fill up the heap memory quickly. A general purpose computer has limited Heap memory . You are not facing this issue ,may be because you did not hit that limit.
Upvotes: 2