Why Unit testing _has_ to be baked into actual assembly

Ignoring for a moment about Dr Neil Roodyn's advice that writing unit-test code into the actual project itself provides facility to test on live deployments (albeit bloated assembly sizes), I just hit a pretty obvious problem of isolated unit-test assemblies/programs - one cannot unit-test internal classes. Additionally for private members and classes, the unit tests have to be directly inside the actual classes themselves as well.

On top of that, looks like NUnit cannot load an assembly's (compiled into .exe) config file for configuration testing.

What are your unit-testing experiences regarding this?

icelava wrote:

Ignoring for a moment about Dr Neil Roodyn's advice that writing unit-test code into the actual project itself provides facility to test on live deployments (albeit bloated assembly sizes), I just hit a pretty obvious problem of isolated unit-test assemblies/programs - one cannot unit-test internal classes. Additionally for private members and classes, the unit tests have to be directly inside the actual classes themselves as well. What are your unit-testing experiences regarding this?

My unit-testing experience tells me that it's a bad idea to include unit-test code inside the actual project itself. I had done that with compiler's directive in the past and I myself was guilty of shipping bloated production code and output tracing statements that pop the eyeball out of customers. Many developers including myself often forget to switch to release mode in the final build. Do put your unit-test code to test internal and private classes, but remove it as soon as the job is done.

In my previos project, we had seperate dlls for unit testing, and they would bring those to debug on the prod. svr...

Thanh wrote:

Do put your unit-test code to test internal and private classes, but remove it as soon as the job is done.

That is assuming you never have to unit-test again upon project sign-off? Would maintenance/enhancement developers be given those "discarded" unit tests in some format for them to "plug in"?

xtreme.net wrote:

and they would bring those to debug on the prod. svr...

And what of internal/private elements? Unless you consider the assembly with its public classes as the only interfaces that need to be tested, and anything else internal is free for developers to mix-match/refactor.

icelava wrote:

And what of internal/private elements? Unless you consider the assembly with its public classes as the only interfaces that need to be tested, and anything else internal is free for developers to mix-match/refactor.

Yes that is a prob which was solved using tons of public properties, but it created lot of unnecessary code! Might as well bake the testing into the asm...

icelava wrote:

That is assuming you never have to unit-test again upon project sign-off? Would maintenance/enhancement developers be given those "discarded" unit tests in some format for them to "plug in"?

We keep the unit-test code in a small project documented its intent. At that time, we had to do everything manually because the private and internal sections are not often touched. We were thinking of writing a "code Injector" or a "plug in" like you suggest to automate the testing process, but it was abandoned due the infrequency of this sort of testing and budget constraint.

icelava wrote:

Ignoring for a moment about Dr Neil Roodyn's advice that writing unit-test code into the actual project itself provides facility to test on live deployments (albeit bloated assembly sizes), I just hit a pretty obvious problem of isolated unit-test assemblies/programs - one cannot unit-test internal classes. Additionally for private members and classes, the unit tests have to be directly inside the actual classes themselves as well.

Agree.  My current experiences also point to the same issues. Of course, complier directives is one way to remove the unit tests out of the release codes.  But then how do you "plug-in" the unit tests during post-deployment?

On top of that, looks like NUnit cannot load an assembly's (compiled into .exe) config file for configuration testing.

Why not? Works fine for me.

Cyrus Crypt wrote:

icelava wrote: On top of that, looks like NUnit cannot load an assembly's (compiled into .exe) config file for configuration testing. Why not? Works fine for me.

Perhaps I am using a wrong approach: the Windows Forms/Service project has its app.config. Which should be renamed into project.exe.config upon compilation. But those are just facade projects; the real working code is in a class library assembly, but depends heavily on the facade's app.config settings.

If I launch NUnit, it is NUnit that is the launching assembly, and loading my class library independently, has no hooks into whatsoever .config file. So it will fail. How do I overcome this shortfall?

icelava wrote:

Perhaps I am using a wrong approach: the Windows Forms/Service project has its app.config. Which should be renamed into project.exe.config upon compilation. But those are just facade projects; the real working code is in a class library assembly, but depends heavily on the facade's app.config settings. If I launch NUnit, it is NUnit that is the launching assembly, and loading my class library independently, has no hooks into whatsoever .config file. So it will fail. How do I overcome this shortfall?

 

Try having a config file that is named after the assembly.  For example, if the assembly is dalc.dll, then the config should be dalc.dll.config.  They should be in the same path.  NUnit will load that. Try and let me know?

The NUnit testing assembly is actually an .exe, and has its <file name>.exe.config output by its side. Having NUnit-gui load that assembly seemingly doesn't have it load its companion .config.

I tried to copy my custom <appSettings> values and paste them into C:\Program Files\NUnit V2.1\bin\nunit-gui.exe.config but it still complains of the absence of those value keys.

Can I upload screen captures?  You're missing my point.  Icelava, maybe IM me, we will discuss. 

that the Unit testing framework for Visual Studio 2005 has a nifty mechanism to test private members.

Open in Document Explorer 8.0
ms-help://MS.VSCC.v80/MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VSENT.v80.en/dv_vsetlt01/html/2b018b18-b412-4e0e-b0ee-b580a2f3ba9c.htm

Also, a fellow developer who faced this same problem and wanted to have VS.NET convert all private/internal members to public if the build configuration is Debug but have them revert to their real modifier in Release mode. I found out this can be made possible with preprocessors

#if DEBUG
    public void DoSomething()
#else
    internal void DoSomething()
#endif
{
    // code here....
}

icelava wrote:

that the Unit testing framework for Visual Studio 2005 has a nifty mechanism to test private members. Open in Document Explorer 8.0 ms-help://MS.VSCC.v80/MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VSENT.v80.en/dv_vsetlt01/html/2b018b18-b412-4e0e-b0ee-b580a2f3ba9c.htm Also, a fellow developer who faced this same problem and wanted to have VS.NET convert all private/internal members to public if the build configuration is Debug but have them revert to their real modifier in Release mode. I found out this can be made possible with preprocessors #if DEBUG     public void DoSomething() #else     internal void DoSomething() #endif {     // code here.... }

 

Icelava, this is a cool idea.  I like it. 

However, it does seem a bit "unorthodox". LOL... 

icelava wrote:

that the Unit testing framework for Visual Studio 2005 has a nifty mechanism to test private members. ..... #if DEBUG     public void DoSomething() #else     internal void DoSomething() #endif {     // code here.... }

This is cool

icelava wrote:

that the Unit testing framework for Visual Studio 2005 has a nifty mechanism to test private members. Open in Document Explorer 8.0 ms-help://MS.VSCC.v80/MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VSENT.v80.en/dv_vsetlt01/html/2b018b18-b412-4e0e-b0ee-b580a2f3ba9c.htm Also, a fellow developer who faced this same problem and wanted to have VS.NET convert all private/internal members to public if the build configuration is Debug but have them revert to their real modifier in Release mode. I found out this can be made possible with preprocessors #if DEBUG     public void DoSomething() #else     internal void DoSomething() #endif {     // code here.... }

Fyi, I have started using this method in my latest project. 

Just one minor issue.  This does mean that we cannot unit test a production assembly. 

I don't do that.  However, just to check, does anyone run unit test on production asseembly?  Does anyone see any issue with this?