Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

test runner process reuse
johanohrn
#1 Posted : Wednesday, July 5, 2017 10:00:00 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 5/2/2017(UTC)
Posts: 8
Location: Sweden

Thanks: 1 times
Was thanked: 2 time(s) in 2 post(s)
Hi,

I'm not sure if this qualifies as a bugreport and/or feature request or just asking for help so I make this post.

This is somewhat related to the following forum post but rather expands upon it.

Generally ncrunch will reuse a test runner when instructed to do so by rightclicking a test, choosing advanced and then debug/run in existing test runner.
However if this will work or not seem to depend on under what circumstances the test runner process was created.
a) If the test runner was created as a result of choosing debug/run in existing test runner then this process will be reused when repeating that action.
b) If the test runner was created as a result of the engine running a testmethod due to it changing then this test runner process will be reused when debugging/running a test method in existing test runner.
c) If the test runner was created as a result of the default debug/run test method (i.e. in new process) then this process will never be reused when debugging/running a test method in existing test runner. Instead a second test runner process will be spawned.

To me this case C is inconsistent with the behavior of cases A and B especially since the behavior of the engine is to spawn a new process whenever it automatically runs one or more test methods. So case B and C are in direct conflict with each other.

I was looking for a setting that would control how the engine goes about this and there seem to be no setting to control the test runner reuse. I.e. spawn a new process (as it does now) or reuse an existing process. I also looked into the custom engine mode and I realised that the engine mode simply overrides the ncrunch settings.
If there was a setting that would allow for changing this behavior then the default setting could be to spawn a new process. This would allow for the global override or the creation of a custom engine mode.


So to sum it up I basically would like it if
1) a process spawned as the result of debugging/running a test in a new test runner process was able to be reused instead of just sitting there and hogging memory
2) there was a way to force the engine to reuse the test runner processes when it runs test methods as a result of them changing
3) there was easier access to the debug/run in existing process menu commands

I feel this would give a noticable boost in productivity for my team and for anyone else looking to optimize their test execution.

Thanks,
Johan
Remco
#2 Posted : Wednesday, July 5, 2017 12:57:39 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,976

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Hi Johan, thanks for posting again.

Your analysis of this makes sense. NCrunch has a concept of a 'process pool' in which processes are stored between execution runs. Each process in the pool has a specific signature derived from a range of important variables (such as the project itself, isolation tags, environment variables, etc). NCrunch's mechanism for forcing a test to run in a new process simply extends this signature with a special tag to create a single-use process. This is done for reasons of simplicity of implementation only, and it is possible to change it. Since this is according to the design of the test runner, I don't really consider it to be a bug, but more of a usability issue. Most people are never aware of this because likely very few have the same cost associated with process initialisation that you do.

If I understand your situation though, introducing a setting to make the engine always execute tests using an existing process by default (without needing to run through nested context menus) would eliminate the need for the above logic to be changed. This is because with the right UI options more accessible to you, you would never need to force creation of new processes and would never need to reuse them. Such a config setting would make good sense as a feature request if you'd like to submit it. Having an understanding of how many people would make use of this feature would be an important factor in prioritising its development.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.031 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download