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

Add support for replacement macros in LogFilePath #2

Open
jrr opened this issue Dec 31, 2018 · 8 comments
Open

Add support for replacement macros in LogFilePath #2

jrr opened this issue Dec 31, 2018 · 8 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@jrr
Copy link

jrr commented Dec 31, 2018

When I run dotnet test at the solution level, results are placed within each test project like this:

Foo.Test/TestResults/TestResults.xml
Bar.Test/TestResults/TestResults.xml

I'd like to produce output like this:

test-results/
   Foo.Test.xml
   Bar.Test.xml

I can get part way there with dotnet test --logger "junit;LogFilePath=../test-results/foo.xml", but then all my test suites will rewrite the one foo.xml file.

Is it possible to emit filenames based on the name of the test project? (If not, consider this a feature request!)

@thzinc
Copy link
Contributor

thzinc commented Dec 31, 2018

@jrr, I can confirm that the logger does not currently support writing multiple files in the way you described as desired.

I think a supporting change could be made to allow something like MSBuild-style replacement macros in the LogFilePath. (e.g., LogFilePath=../test-results/$(Source).xml) In looking at TestResultInfo, I don't know if anything beside TestCase.Source would make much sense for this feature.

I think this could be implemented in TestRunCompleteHandler by checking outputFilePath for $(Source) and grouping resultList by TestCase.Source.

For a fuller understanding of what you're trying to accomplish, what are you ultimately wanting to do with files in this different location? Could you append a && find -name TestResults.xml -exec mv {} test-results \; (or something similar) to the end of your dotnet test command? Could your use case be solved if this logger just appended to the file defined at LogFilePath instead of overwriting it for each project?

@thzinc thzinc added the enhancement New feature or request label Dec 31, 2018
@jrr
Copy link
Author

jrr commented Dec 31, 2018

My use case is reporting results to CircleCI.

I'm currently working around the issue by copying/renaming the files, but am hoping to eventually avoid that.

Appending to one file would be an improvement, but then all the tests would belong to one "suite" in Circle's view.

@thzinc
Copy link
Contributor

thzinc commented Jan 7, 2019

@jrr, thanks for the context. I'm going to update the title of this issue to reflect the feature change. I won't be able to pick up this enhancement in the near term, but I'm open to accepting a PR if you (or anyone else) wants to implement the replacement macro feature as described.

@thzinc thzinc changed the title per-suite file name? Add support for replacement macros in LogFilePath Jan 7, 2019
@thzinc thzinc changed the title Add support for replacement macros in LogFilePath Add support for replacement macros in LogFilePath Jan 7, 2019
@thzinc thzinc added the good first issue Good for newcomers label Jan 7, 2019
@viceice
Copy link

viceice commented Jan 23, 2019

I think a runtime macro would be helpful too. We are have tests for netcoreapp2.1 and net452.
So the second run would owerwrite the first run results.

@viceice
Copy link

viceice commented Jan 23, 2019

@thzinc
Copy link
Contributor

thzinc commented Jan 24, 2019

@viceice, regarding the target framework, do you know of a way to reliably get the target framework at runtime? Also, does the trx logger actually produce files with username, hostname, and date in the filenames?.

@viceice
Copy link

viceice commented Jan 24, 2019

@thzinc I only know RuntimeInformation.FrameworkDescription.

Yes, the trx logger does exacly that.

@8
Copy link

8 commented Mar 2, 2020

Any news on this issue?

ATM this makes running dotnet test on the solution file not useful, e.g.:

dotnet test src/solution.sln --logger junit --results-directory TestResults

with the 2 test projects creates a single TestResults.xml because the first one is overwritten.

Take care,
Martin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Development

No branches or pull requests

4 participants