Showing posts with label nuget. Show all posts
Showing posts with label nuget. Show all posts

Tuesday, February 7, 2012

Moving PostSharp to another project

I am currently using PostSharp to add logging and exception handling aspects (to name a few) to an application. PostSharp does this very well and my code has become quite a bit more readable thanks to it. PostSharp actually weaves in extra functionality during your build process. And it can be easily added to an existing project using a nuget package installer.

A recent change in the application however had me refactor out some of the classes I'd added aspects to, to another assembly in the same application. After the refactoring I also added the PostSharp dll to the new project and realized my aspects weren't added/weaved in during the build. This had me thinking, since I did add the PostSharp dll to the new project. After some searching, I found the source of the problem.

Since PostSharp adds extra functionality during your build, you'll need to tell your project (or the C# compile process, that is) to execute this extra PostSharp funcationality. The nuget package actually added this to my original project, but not to any other project in the same solution. So, to solve this, either rerun the nuget package installer on the other project, or, just as easy, add the following xml tag to your csproj file (somewhere at the bottom).

  <Import Project="..\packages\PostSharp.2.1.5.1\tools\PostSharp.targets" />

You get this explanation as well in your projects' properties. You will notice an extra PostSharp tab there, that is either enabled - if PostSharp is doing its' thing - or disabled - if it is not, which was the case for me.

Tuesday, July 5, 2011

Playing GOLF

Qframe recently held a bootcamp where all employees were invited to follow sessions on all kinds of things. One of those was a code retreat in which we tried to implement as much of the Game Of Life as possible in 45 minutes time, while giving ourselves a couple of restrictions (implement this without using if statements, implement this test first, ...). We redid this exercise a couple of times and during the last go, I and some colleagues gave ourselves the restriction of using a completely different language than the one we are used to. So we tried implementing this in F# (hence the name GOLF: Game Of Life in F#). I must say, we didn't get very far, but ever since I have been playing with the idea of finishing this exercise. In this post you will find my experience in trying this.

First of all, I must admit, I do have some experience in functional programming. This doesn't mean however I am a bright and shining light in functional programming (all but). But I have used Scheme for a year at university and I still know what a car and cdr are, what a REPL loop is, and so on. On the other hand, I am pretty sure that in the GOLF exercise I made some very big errors in functional programming and I hope you, as a reader, are a bit forgiving for those. One thing that's new to me is the fact that I can mix a functional style with objects. So, feel free to comment on the code, since I do want to learn from my mistakes!

To get started I needed an F# project. I choose to use an F# Library project, since I wanted to start with all the logic of the game first, a fancy user interface can be added later. This type of project gives you two files, a Module1.fs file, in which to place your code and a Script.fsx file, in which you can write code to informally test your F# program. Since I am going to use a unit testing framework to test the F# code, I removed the .fsx file.

Another thing you need to be aware of when writing F# code, is the order in which you place your files. They are processed in order by the F# compiler, so make sure a type (or function, or whatever) is known by the compiler before you use it. This sort of looks like the behaviour you have with a C++ compiler, where you need the correct include statements to let types know each other. A C# programmer doesn't need to worry about this, since all types within the same project know each other.

After the basic project setup, I wanted to write this application test first. So after some Google research I found a couple of unit test libraries you can use with F#. In fact you can use the NUnit framework if you want to, but I choose to use FsUnit, which adds a more natural style of writing tests for F# (and uses NUnit to annotate its tests). Since the FSUnit project is hosted on nuget, installing it, was quite easy (install-package fsunit and you're done). The nuget package also adds a .fs file that gives you some example test cases to get started. I didn't go into the effort at first to place my test code in a second F# library project. I can still do this later on. I did place the test code in a second .fs file (after the Module1.fs file).

Ok, so on to writing my first test. I started simple in saying that when I create a new Cell in the Game Of Life, it shouldn't have any neighbours. F# has the notion of namespaces, you can add those at the top of your file. If you want to use functionality from other libraries (like NUnit, FsUnit and the module1 file I am writing tests for), you need to add an open statement for each. This is actually similar to writing using statements for namespaces you want to use. After this you can place your first test class. in my case this class is called ''Given a new cell''. This naming style is handy when looking at your tests in a test runner. F# (or FsUnit, I actually don't know which) permits spaces in the class name, as long as you surround it with quotes. Beware though, these are two single quotes that start at the top left corner and end at the bottom right corner (they do NOT go straight down, look for them on your keyboard!). Since this is a test class, you need to decorate it with the TestFixture attribute.

 namespace GolF.Tests 
  
 open NUnit.Framework 
 open FsUnit 
 open Module1 
  
 [<TestFixture>]  
 type ``Given a new cell`` ()= 
   let cell = new Cell() 
  
   [<Test>] member test. 
    ``when I ask how many neighbours it has, should answer 0.`` ()= 
       cell.numberOfNeighbours |> should equal 0  

The actual test creates a new Cell class, which I still need to implement, I am working test first. And after that you can find my first test. Again, I use the fact that you can place an entire sentence between those funky quotes. The test is annotated with the Test attribute and I also indicate this test method as being a member of the test class. Beware though that F# does a lot of its parsing based on indentation, so indenting in the correct way is really important. After I wrote my first test, the F# compiler was actually complaining about the ``when I ask how many neighbours it has, should answer 0.`` sentence, which I found strange. The FsUnit example file, with the same sort of syntax, compiled just fine. After some really hard looking at the two files, I found out that before the sentence there is not only a tab, but also a white space, which is very easy to miss.

With this test written, it was time to get it compiling, meaning I had to provide a Cell type with a numberOfNeighbours member.

 module Module1 
  
 type Cell =  
   val numberOfNeighbours : int 
   new() = { numberOfNeighbours = 0 } 

This immediately made my test green, which actually isn't good practice, but I'll ignore that for now.

Time to add some more tests. I will finish this little application during the next weeks and will post some more about my findings during that time, until we get a finished Game Of Life example. I hope this short post will be enough to get you started in F# projects for now.

Friday, April 29, 2011

Unit Test Windows Phone 7 Project

In the windows phone 7 course I recently followed, there was an issue in unit testing a windows phone 7 project (you can find my recent post on this course here). The fact is, you can't create a Visual Studio unit test project for your phone project. Does this mean you cannot unit test your project? Of course it doesn't! Here's a solution to this problem.

First of all, I am using the MVVM pattern in my windows phone 7 project. This means my views, viewmodels and models are separated from each other, so I can place them in different projects. I created a normal windows phone 7 project for my views and a different windows phone 7 class library project for my viewmodels and models. Next thing you can now do is create a third project, also of the windows phone class library kind, which will contain your unit tests. You can see this basic setup in the following picture.

The fact that you take a windows phone 7 class library project for your unit tests is important. This solution will not work if you choose to use for instance a Silverlight class library project.
To this test project I now added the NUnit and Rhinomock dll's using Nuget and with this I can test all I want. One thing I still encountered was an error in my Unit Tests telling me the System.Windows dll could not be found.

This is quite a weird error, especially since the System.Windows.dll is present as reference in the test project. I tried adding different versions of this dll (all in my C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone folder), but no luck. Eventually I found that the dll was present in the project, but it just didn't get copied to the bin/Debug folder. Changing its Copy Local setting to True did the trick (and I kicked myself for losing quite some time on this stupid error).
So, there you go, a quick and easy way to unit test windows phone 7 projects. Soon I hope to give you some posts about my first Silverlight game and after that my first XNA game.