This project is read-only.

Enhancement: search nbits file in current folder

Nov 23, 2012 at 4:36 PM

One of my concerns is that I want to use nbits on a continuous integration server. Nothing would prevent 2 nbits files to run in parallel.

As of today, each nbits file is packaged with the bunch of DLL files to run the tests. It would be much more relevant to have only a single set of DLL files somewhere and have only the nbits files as the testing package, without the DLLs.

I could use the config file to indicate the apropriate folder/file to use, but nothing would prevent a collision when 2 tests start at the same time and want to modify this file - or one modifying while the other one is reading.

Another option would be that the test file is searched in the working directory. So if I have

C:\myTests\myTest.nbits
I can call
C:\programs\nunit\nunit.exe C:\Nbi\NBi.NUnit.Runtime.dll
from the working directory
C:\myTests

and it would work fine.

Can this be implemented?

Thanks

Cedric.

Nov 25, 2012 at 10:09 PM

I understand your need and I share your point of view that it's not a good idea to copy the set of dll everywhere. Neither, it doesn't sound to be a viable solution to update the config file on the fly.

To be honest, I don't fully understand your solution ... but I think I'll be stopped when I'll reach the point where I need to send a parameter to NUnit and this parameter must be used by NBi. I've already take a (quick) look to this and it wasn't a success. I'll retry and check this again.

On my plans, I've another option that could be interresting for you. When you'll execute NUnit on the dll "NBi.NUnit.Runtime.dll", this dll will check if its filename is really "NBi.NUnit.Runtime.dll", if not it will search the nbits file with the same filename to read the test-suite it contains (so if the filename of the dll is "MyProjectOne.dll", it will read "MyProjectOne.nbits" in the same folder), it will also do the same with the config file. 

Dec 10, 2012 at 2:33 PM
Edited Dec 10, 2012 at 2:41 PM

Hello,

Thank you for your reply and your help. Unfortunately this doesn't solve that.

I had a look at the code, here is my suggestion in details:

When you seach for .nbits files, you look into the assembly folder:

var files = System.IO.Directory.GetFiles(Path.GetDirectoryName(assem), "*.nbits")

I propose that you also search in the working directory:

 

files = System.IO.Directory.GetFiles(Directory.GetCurrentDirectory(), "*.nbits");

 

As a consequence, if I have a .nbits file alone in my local folder, where I run the test from, then this file will be found.

I agree with you that the parameters are an issue in this implementation. It will simply not be possible to pass information to the test library other than by config or nbits file. My proposal there would be to search for the config file in the working directory too, or to get rid of the config file and include everything in the nbits file... which would make things simpler.

Cedric.

Dec 10, 2012 at 2:54 PM

Hi Cedric,

What do you mean by  "if I have a .nbits file alone in my local folder, where I run the test from"? How do you know the folder where you're running your test from?

For the moment the implementation is that this folder is the folder containing the dll NBi.NUnit.Runtime.dll. I'd be pleased to change this to the folder where the nbits file is standing. But how do you want to achieve this? Take into account the flow of knowledge: Your entry point is NUnit and you've a parameter which is the location of the dll "NBi.NUnit.Runtime.dll". Then, once you're in this dll how do you know where you should look after the .nbits file?

I think that the solution is in the "appbase path" of NUnit but still haven't understood the real purpose of this attribute and the documentation on it is really poor.

About your solution of using Directory.GetCurrentDirectory(), this solution doesn't work on a standard environement because the CurrentDirectory is by default the location of your program, so both Directory.GetCurrentDirectory() and Path.GetDirectoryName(assem) should return the same location. I will confirm this tonight.

Dec 10, 2012 at 3:18 PM

OK, I tried to implement it and it looks like NUnit is changing the working directory to the directory of the test DLL, which is fatal for my proposal.

Dec 11, 2012 at 12:47 PM
Edited Dec 11, 2012 at 12:48 PM
seddryck wrote:

About your solution of using Directory.GetCurrentDirectory(), this solution doesn't work on a standard environement because the CurrentDirectory is by default the location of your program, so both Directory.GetCurrentDirectory() and Path.GetDirectoryName(assem) should return the same location. I will confirm this tonight.

Just to bring a bit of clarification: if you launch a command prompt and go into your "documents" folder (c:\ users\me\documents), and from there run c:\windows\notepad.exe. Then the Path.GetDirectoryName(assem) returns c:\windows\ while Directory.GetCurrentDirectory() returns c:\ users\me\documents. But in the specific case of NUnit, it looks like before calling the tests, NUnit changes the current working directory to the directory of the test DLL. This is confirmed by what I can read here

The good news is that it is possible to get a test directory indication in a TestContext. That is TestContext.CurrentContext.WorkDirectory

The bad news is that this value is not defined at the moment when GetTestSuiteFileDefinition is called

The good news is that is is defined at the instanciation time, that is when TestSuite constructor is called.

So the solution is:

  • locate the .nbits file in the constructor using TestContext.CurrentContext.WorkDirectory + the other options already implemented (assembly name, config file) and store it in a local variable
  • use this local variable in GetTestSuiteFileDefinition to read the contents of the file

If you agree, I'd be glad to join the team and implement this.

Dec 11, 2012 at 3:07 PM

Indeed it looks promizing. You're welcome to submit your pull request to enable this feature.

Have you read my private answer to your request?