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

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...

Solution

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()