Unit testing of Code Modules vs .NET Assemblies

  • 24 July 2007
  • 5 replies
  • 2 views

Badge +1

I'm fairly new to K2 and have inherited a project where a lot of code modules are used. There is a big push to write unit tests for these existing code modules. I would imagine that it would be easier to copy these code modules to .NET assemblies and gain the advantage of unit testing inside VS.NET with NUnit and TestDriven.NET.


Anyone have any thoughts on this before I actually start the creation of these .NET assemblies?


Are there any advantages to using code modules as opposed to .NET assemblies?


5 replies

Badge +5

Hi leftside,


Feel free to port these code modules over to .NET assemblies.  You will gain the full richness of Visual Studio (ie: your unit testing requirements) and you can simply reference your .net assemblies from K2.net Studio by adding a reference and setting the correct import statements.  There is a locking issue that I want to make you aware of however.


K2.net Studio uses reflection to determine the interface exposed by the referenced assembly in the Web Service & Assembly template as well as the code editor.  Whih means that the assembly needs to be loaded into an application domain in the .net framework. So far so good, but the problem stemps from the fact that the lock on the file isn't released when the reflection calls are complete cecause the assembly isn't unloaded.  In the 1.1 framework, on which K2.net Studio and all template are built there is no way of forcing an unload and release of the assembly.  So what this means is that you can reference a custom assembly in K2.net studio and you may find that during your development of your custom assembly that K2.net Studio does not and cannot pick up your changes so when you export the old assembly is actually still going to be the one exported. The work around for this is to remove the assembly reference, close K2 studio, open Studio and re-add your reference.


It's a bit of a pain but if your going to unit test your code this should releive the amount of times perform this would be necessary.  Also know that the 2.0 framework has implemented some additional function that allow you to reflect an assembly without having to load it, and further BP is hosted entirely in VS.net.


An alternative to the forementioned is to GAC your assemblies.  The downside is that the assembly will not be serialized to the database so you loose versioning of assemblies with each process definition your export (meaning your GAC'd assembly must fit for all versions of your processes which you can get away with by using overloaded methods), and you must deploy the assembly to the server.


Let me know if you have any other questions.


-mike

Badge +1

Thanks. That is very useful info to know.


I won't be GAC'ing my assemblies as I do need versioning.


Currently trying to persuade the customer to move to BP ;-)

Badge +13

Does this mean that configuring K2 Studio to use .NET FW 2.0 and use a 2.0 assembly will not require (remove reference, close K2 Studio, re-add)?


 

Badge +5

Hi Peter,


In Regards to K2.net Studio 2003 or [BlackPearl]?

Badge

Excellent to know Mike. 


I've experienced this myself and was not sure of why.  Glad to know it's not an issue in BP.

Reply