Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Extend <start-run> data for ITestEventListener #625

Closed
elv1s42 opened this issue May 17, 2019 · 7 comments
Closed

[Feature] Extend <start-run> data for ITestEventListener #625

elv1s42 opened this issue May 17, 2019 · 7 comments
Assignees
Milestone

Comments

@elv1s42
Copy link
Contributor

elv1s42 commented May 17, 2019

Hello,
This is not a bug but a feature request to improve this extension: https://github.com/nunit/docs/wiki/Event-Listeners.

At the moment I think we don't have enough information about the tests when run is started.
Consider the following example:

[Extension(Description = "My NUnit Extension")]
public class MyEventListener : ITestEventListener
{
     public void OnTestEvent(string report)
     {
         var xmlNode = XmlHelper.CreateXmlNode(report);

         switch (xmlNode.Name)
         {
             case "start-run":
             {
                 //Some custom logic here...
                 break;
             }

At the moment the only data I'm getting here is the string <start-run count='0'/>
But it whould be nice to get some information like test run start DateTime, the command which is used to run the tests, engine version, clr version.

The use case for this change is simple: this data can be used for creating custom real-time test run reports based on ITestEventListener extension point.

I did a small investigation and it looks like the change should be quite simple, we could extend RunTests method here (@CharliePoole, please correct me if I'm wrong)

If you agree this is a useful feature I can prepare pull request with possible code changes, but first we may need to choose the data to be available in <start-run> section.

Thank you

Regards,
Evgeniy

@CharliePoole
Copy link
Member

I'll leave the usefulness of this up to the @nunit/engine-team.

If it is done, those elements, which are now added to the test-run element, would have to be additionally added to the start-run element.

@ChrisMaddock
Copy link
Member

I'd have no objection to accepting a PR here. @elv1s42 - would you come up with a list of the items you'd want to add? I wonder if we should instead have a convention, that start-run will contain all the same elements that test-run does. (Wherever possible)

By the way, if you're planning on making use of this event, are you aware of this outstanding issue?
#441

@elv1s42
Copy link
Contributor Author

elv1s42 commented May 20, 2019

Hi @ChrisMaddock and @CharliePoole !

Thank you very much for quick response.

I agree the start-run should include (if possible) the same arguments as test-run, but what should I do with command-line? I think it should be the child of run-start.

So now we have this run-start element:

<start-run count='0'/>

I'll include some more data and start-run will look like this:

<start-run count='0' engine-version="3.8.0.0" clr-version="4.0.30319.42000" start-time="2018-07-04 08:36:04Z">
   <command-line><![CDATA[C:\_NUnit3.8\nunit-console\nunit3-console.exe  C:\Tests\SomeTests.nunit]]></command-line>
</start-run>

So the total list of new elements is:

  • engine-version as a new attribute for start-run element
  • clr-version as a new attribute for start-run element
  • start-time as a new attribute for start-run element
  • command-line as a child of start-run node

Please confirm the list of elements and their location.

Regards,
Evgeniy

@ChrisMaddock
Copy link
Member

This looks good to me - would be good just to get confirmation from others someone else on @nunit/engine-team before going ahead. 🙂

@CharliePoole
Copy link
Member

Looks good to me as well.

@elv1s42
Copy link
Contributor Author

elv1s42 commented May 21, 2019

Hi @ChrisMaddock,

I've implemented the changes here

Thank you

@mikkelbu
Copy link
Member

#629 did not auto-close this issue, as "Resolving" is not one of the recognised keywords.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants