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

Update the plugin to allow a configurable start #49

Merged
merged 1 commit into from
Jul 10, 2018
Merged

Update the plugin to allow a configurable start #49

merged 1 commit into from
Jul 10, 2018

Conversation

costin-zaharia
Copy link

Adds nunitCommandModifier config which if set, can overwrite
the default command arguments in order to allow running of
external tools like dotMemoryUnit.

@panteamihai
Copy link
Contributor

LGTM

Copy link
Contributor

@dfev77 dfev77 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should add some tests to cover the new functionality

@costin-zaharia
Copy link
Author

@dfev77 I've added unit tests to cover the new functionality

@costin-zaharia costin-zaharia changed the title Update the plugin allow a configurable start Update the plugin to allow a configurable start Jul 9, 2018
Adds nunitCommandModifier config which if set, can overwrite
the default command arguments in order to allow running of
external tools like dotMemoryUnit.
@panteamihai
Copy link
Contributor

+1

@gluck
Copy link
Contributor

gluck commented Jul 10, 2018

Seems like you took a different approach for integrating dotMemory than what was done for opencover, is it on purpose ?
In particular, not having a dotMemory plugin means that the executable will have to be installed/available on the machine running the build ?
Also will it still integrate nicely with opencover, or will users have to choose between coverage and memory tests ?

@timotei timotei merged commit 3a25ef8 into Itiviti:master Jul 10, 2018
@costin-zaharia
Copy link
Author

Seems like you took a different approach for integrating dotMemory than what was done for opencover, is it on purpose ?

ignorance not purpose :) I will take a look on opencover to see if I can apply the same approach

In particular, not having a dotMemory plugin means that the executable will have to be installed/available on the machine running the build ?

not needed since the dotMemoryUnit.exe tool is part of the referenced nuget package

Also will it still integrate nicely with opencover, or will users have to choose between coverage and memory tests ?

I will check and come back with an answer

@costin-zaharia
Copy link
Author

Seems like you took a different approach for integrating dotMemory than what was done for opencover, is it on purpose ?

I've took a quick look on the opencover nunit plugin and that approach seems to be a lot more extensible for future improvements but, as far as I can tell, for the moment we don't need that extra flexibility since there is no other customisation needed than running the tests on dotMemory environment.
In this specific case the tool is already downloaded by the nuget restore.

An usage example: https://blog.jetbrains.com/dotnet/2015/09/15/memory-testing-on-a-ci-server-dotmemory-unit-standalone-launcher/

dotMemoryUnit.exe -targetExecutable="C:\NUnit 2.6.4\bin\nunit-console.exe" -returnTargetExitCode --"E:\MyProject\bin\Release\MainTests.dll"

From another point of view the nunitCommandModifier is generic enough to be used in other contexts by providing a way for customising the arguments passed to the runner. (Maybe a fix for #30?)

Also will it still integrate nicely with opencover, or will users have to choose between coverage and memory tests ?

As far as I can tell, opencover is building it's own command ignoring the nunit one so they will integrate nice but there is a downside: since both dotMemory and opencover need the tests to be run in their own environment, the users will have to run the tests twice if both coverage and memory testing is needed.

@gluck
Copy link
Contributor

gluck commented Jul 11, 2018

Irt #30 it could be used, though I don't think that approach is good, for the same reason(s) I mentioned on the ticket.
How does dotMemory assertions behave when ran through plain nunit (or opencover) ? won't they fail the tests ? Shouldn't we have something like opencover run dotmemory run nunit ?

@costin-zaharia
Copy link
Author

How does dotMemory assertions behave when ran through plain nunit (or opencover) ? won't they fail the tests?

The behavior of the memory tests can be controlled using an attribute: [DotMemoryUnit(FailIfRunWithoutSupport = false)]

Shouldn't we have something like opencover run dotmemory run nunit ?

I will try to see if it works fine.

@costin-zaharia
Copy link
Author

Shouldn't we have something like opencover run dotmemory run nunit ?

I was not able to run them like you sugested: opencover -> dotmemory -> nunit due to what I assume is an opencover profiler problem:

Committing...
No results, this could be for a number of reasons. The most common reasons are:
1) missing PDBs for the assemblies that match the filter please review the
output file and refer to the Usage guide (Usage.rtf) about filters.
2) the profiler may not be registered correctly, please refer to the Usage
guide and the -register switch.

but I was able to run them the other way around: dotmemoryunit -> opencover -> nunit

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

Successfully merging this pull request may close these issues.

5 participants