Open shaburov opened 6 years ago
@juherr, consent to refactoring.
Set @Deprecate
for old methods and
setTestName()
getName()
getTestName()
Add new methods to the ITestResult
and TestResult
:
setResultTestName(String string)
- string != null && string not emptyString getResultTestName()
- String (default return ITestNGMethod name)setTestMethodName(String string)
-> return UnsupportedOperationExceptionString getTestMethodName
- return real test method name (ITestNGMethod)Make changes to reports (IReporter and etc.)
Make changes to existing test + add new test
@shaburov -
getName()
by default is supposed to be returning back the calculation from one of the following
// Calculate the name: either the method name, ITest#getTestName or toString() if it's been overridden.
getTestName()
is supposed to support the customized test names provided via the ITest
implementation that a test class is supposed to provide. Only if that is provided by a test class, would getTestName()
give you a valid value and in other cases it is supposed to be returning a null (as the java docs say)
So wouldn't the following refactoring be less invasive ?
setTestName()
and add a new method called setName()
I believe the confusion is only because setTestName()
method name is wrongly named. It should have been just named as setName()
(so that its in accordance with getName()
)
Agree to rename setTestName()
to setName()
.
@shaburov Does it fix the issue too?
@juherr I do not think it's a good idea. Renaming the API of a method without @Deprecate
can break the user's implementation.
Although if you look at it from the other side, this is version 7.+ and similar changes are implied.
As you say, I'll do.
@shaburov IMO both options are valid.
But I agree that a deprecation will be more safe and fair.
@juherr @shaburov setTestName
was only introduced in 7.0.0-beta1, so it would have been in fact very easy to rename it to setName
back then.
getName() by default is supposed to be returning back the calculation from one of the following // Calculate the name: either the method name, ITest#getTestName or toString() if it's been overridden.
@krmahadevan that's what the implementation comment in TestResult.init()
says, but the API documentation in ITestResult.getName()
says
@return The name of this TestResult, typically identical to the name of the method.
So the implementation is wrong, and it should have never used the testName from the @Test
annotation, or ITest.getTestName()
.
Other tools, like maven-surefire
, expect ITestResult.getName()
to return a method name, and they report just testResult.getName()
, not testResult.getName() + "." + testResult.getMethod().getName()
:
IntelliJ has a workaround for this bug, but it's only applied when testResult.getTestName().equals(testResult.getTestClass().getTestName())
, so they hope it will be fixed at some point:
@shaburov - Would you be willing to help raise a PR for this ? That way it would be easier to reason out and then track this to closure ?
The expected behavior about name is supposed to be covered by tests: https://github.com/cbeust/testng/blob/master/src/test/java/test/name/NameTest.java
@danberindei Do you think one or more of the tests should be changed? I agree that the documentation should be fixed accordingly.
testng-7.0.0-beta1
interface ITestResult contains methods:
However, the implementation class TestResult return: IInvokedMethod.getTestResult().getName() -> TestName IInvokedMethod.getTestResult().getTestName() -> null
Not only is the result confusing. The implementation of TestResult is contrary to the contract ITestResult.
Playback Code:
Actual console output:
Expected console output:
In my personal conviction, the implementations of the getName () and getTestName () methods are confused.