Is there an implicit alternative to dependsOnMethods TestNG functionality? (running tests in dependent order)

Question

Let us have the following TestNG tests:

@Test 
public void Test1() {

}

@Test (dependsOnMethods={"Test1"}) 
public void Test2() {

}

@Test (dependsOnMethods={"Test2"}) 
public void Test3() {

}

Tests serves as functional end to end webui tests (with Selenium Webdriver). Each test method is a step in context of long e2e scenario.

How can we refactor the tests to make them more readable? The best solution may be to remove all this 'dependsOnMethods' parameters in annotation and provide this 'dependsOnMethods' functionality implicitly. The question is How? Expectations in priority order:

Find a solution keeping TestNG on board
Keep TestNG, but involve any other instrument, e.g. easyb? using groovy instead of java... Can I use TestNG groups with easyb? Is it possible, to easyb not in bdd style but 'junit' style, like:

given "user is logged in and sets expert mode", {
//... setup, a la @BeforeClass 
}

then "user can enable bla bla bla" {
//... 
}

then "user can check poo poo poo" {
//... 
}

then "user save changes" {
//... 
}

then "user revert changes", {
// Tear Down, a la @AfterClass 
}

Is there any problems with 'just starting to write your other test classes in groovy in the same java project'?

Kick TestNG, but use what? TestNG groups feature - is needed.

One of crazy solution may be - broke everything and move to Thucydides. But this is not an option in my case.

PS I know dependent tests is a 'bad practice'. But I believe that 'testing dependencies itself' is also a good point in automation...

I don't understand the problem. What's wrong with having multiple `dependsOnMethods`? I personally believe that this is quite readable — Nathan Merrill, Oct 10 '13 at 12:44

score 1 · Answer 1 · edited May 23 '17 at 11:58

1

Yes.. there is an alternative to using depends on... DONT DO IT!

As i've answered here...

This is terrible test logic.. As an experienced professional software test engineer.. I advise you to immediately disperse from this automation path that you are on.

Good test architecture requires that each method be SELF-SUFFICIENT and should not depend on other tests to complete before continuing. Why? Because say Test 2 depends on Test 1. Say Test 1 fails.. Now Test 2 will fail.. eventually, you'll have Test 1,2,3,4,5 tests failing, and you don't even know what the cause was.

My recommendation to you sir would be to create self-sufficient, maintainable, and short tests.

This is a great read which will help you in your endeavours: http://www.lw-tech.com/q1/ug_concepts.htm

edited May 23 '17 at 11:58

Community

1
1

answered Oct 10 '13 at 14:04

ddavison

28,221
15
85
110

I completely understand you idea. I have separate suites where tests are extremely clean and self-sufficient. But I thought, that there is a place in the world of QA Automation, where 'dependent' tests also may exist. What if the goal is to test 'dependencies' itself? That was the point of that 'end to end functional tests' from user perspective. When e.g. user enables and customizes some service on one one web page, than go to the other one, and try to customize another service, and fails, just because of that dependency established in the first 'steps'. Is this not a good idea to be tested? – yashaka Oct 11 '13 at 06:04
I understand that everything should be tested at its place at the very beginning. And such services should be tested on unit and integration level, with correspondent tests with stub/mock/fake services, etc. But what if at current stage of the project, nobody will do this among developers? What if this services are hardware dependent, and on hardware side - also, nobody will test them:) All I have now - is to emulate the real user scenario with all dependencies he can do to have at least some automation tests that will be not very accurate but at least will serve as a good smoke CI suite. – yashaka Oct 11 '13 at 06:09
Nevertheless, thank you for your point. I knew this, but sometimes can just not pay enough attention to the subject in this context. I should clearly spend more time to review everything and try to reduce the amount of dependencies. – yashaka Oct 11 '13 at 06:12

score 1 · Accepted Answer · answered Oct 18 '13 at 11:01

Keep TestNG, but involve any other instrument, e.g. easyb? using groovy instead of java... Can I use TestNG groups with easyb? Is it possible, to easyb not in bdd style but 'junit' style

This is the choice I Used.

You will have no testng like groups with easyb (at least out of the box), and I didn't find so far any way to 'anotate' easyb/groovy 'test methods'.

But, now I have:

implicit dependent methods. Though they are not fully dependent - if some methods will be 'disabled' the next ones will be still executed. But the my actual goal can be achieved: since the test file is a groovy script, all 'test methods' will be executed in the order they are written. Once you need to disable any 'test method' you can simply comment its code - this will disable test from execution and show it as 'pending' in the report.
test methods have readable "sting" names.

This is how tests can look:

beforeAllSetup()

before "each method setup", {
  //implementation
}
after "each method tear down", {
  //...
}

it "first test this", {
  //...
}

it "this will be shown as pending in the report", /*{
  //...
}*/

it "then test this", {
  //...
}

afterAllTearDown()

Is there an implicit alternative to dependsOnMethods TestNG functionality? (running tests in dependent order)

2 Answers2