This closes #863 Same xmlsuite is added multiple times when tests are run using TestNG.SetXmlSuites method

[virenv]

No description provided.

[juherr]

Oops, I think this line is not expected ;)

[virenv]

New to Java and git :(, just fixed it up.

[juherr]

:) You can try to squash all your commits into only one with git interactive rebase. It's for advanced git users but it's really useful.

[juherr]

Move suitePath and rootPath between the 2 for.

[virenv]

s.getFileName() can return null in surefire plugin suites. By putting it here we will avoid the surefire plugin case and avoid a null check.

[juherr]

s.getFileName() can return null in surefire plugin suites

Are we agree it is a surefire issue? Do you have an example ?

[juherr]

Instead, what do you think to change parse method to XmlSuite parse(String) (which will add children itself into the parent suite)?
And then add an util method like Collection<XmlSuite> getAllSuite(XmlSuite parent) where we need all suite of the graph.
My proposition is a bit more intrusive but sounds better IMO.

[virenv]

Let me take a look at it tomorrow, will update you on this

[virenv]

There are two things here

1. parse() has a contract which says it will parse the current suite and also any children that it might have. So its perfectly fine for parse method to return this
2. Its a public method and will be kind of a change that will impact all who have used this way of running tests. Unless we are trying to add an overload of XmlSuite.parse

This was my original thinking to fix the problem. I dont think that we should try to change much if issue can be fixed with a surgical and logical code change.

If you still think that what you have suggested should be done, please explain more to me about your approach may be with some example.

[juherr]

Maybe you are right but nobody is supposed to use the Parser class.
And I still think the parse() contract has no sense and should parse the current suite, its children and add them instead.

BTW, at least, I suggere to add a new method that will parse children only. Currently, even the variable name is wrong: childSuites.
I think it is better to have this logic into Parser instead of TestNG.

[virenv]

It seems to make sense now, Parse should parse the given XmlSuite and if it find any child it should add as the child to that suite.
However, this is only one level of nesting, what about multiple level of nesting? for eg one suite points to another suite which in turn point a one more suite file.
What I think is that it should be recursive in nature and complete tree should be built from the parent suite to all the children to any given depth.

Let me know you thoughts and let me rewrite the logic after that. However, I still think that if Parser class is not meant to be used by everyone then is this much change worth? But as its a public API, I ended up using it anyway. Same is true for other people, they might have used it with the current contract of parse(). Will that not be a breaking change for them?

[juherr]

However, this is only one level of nesting, what about multiple level of nesting?

For sure, we need some recursive here.

I still think that if Parser class is not meant to be used by everyone then is this much change worth?

I'm agree. But we can add a new method, or an util method that will filter the existing one.
I think the parsing logic should be located in the same class.

[juherr]

Could you add a test for #829 too? We should check that it is still possible to add the same child suite many times.

[virenv]

Same child suite will point to same tests, same tests will fail the check in checkTestNames this method. That is the confusion I have. I am seeing the exception about same test name for two tests in one suite. Lets deal with this in a seperate issue. I will open one for this.

[virenv]

Let me pick this up as a part of next issue. I will log one after understanding the problem in details.

[juherr]

Typo: SuiteListener

[juherr]

@virenv I'd like to make a release soon. Do you think we will be able to close this pull-request before?

[virenv]

@juherr I am little bussy till the end of this week. I think by the end of this week I should be able to send a PR. Will that be fine, when are you looking for a release?
On a separate note, we can safely say that this fix is correct based on current understanding of parse method. We can take care of the refactoring of code of parse in a the next release. I can fix that as a part of separate issue, we can merge this PR for current release. What do you say?

[juherr]

when are you looking for a release?

No date for the moment. We are waiting for another PR too.

We can take care of the refactoring of code of parse in a the next release.

Why not, but in my opinion there are too many open points for the moment.
Don't worry, at least we will add it in the next release.

[virenv]

@juherr I want to inform you that I will take some more time to fix this. I got a crazy schedule this week. Will try to push it in another 4-5 days.

[juherr]

Ok, don't worry. I will try to work on it too. I feel it won't be an easy fix.