So you might be thinking that you want to use the Membership class and the ProfileBase class in Microsoft’s System.Web.Security and System.Web.Providers but then you also want to write unit tests as well so you decide to go stand in traffic instead once you are overcome by the plethora of static nonsense that is the design of these two classes. OK, so it isn’t that bad but it is frustrating however there are ways around it and I wanted to try and blog about some of those techniques in the hope that others won’t have to toil with as much frustration as I did when using these classes.
Backgound
Basically I wanted to find a clean simple way of making use of and extending Microsofts built in forms authentication. It’s easy to use, relatively secure and can save a lot of time and code, well sort of until you want to unit test. The ProfileBase class is great for extending profiles and adding custom properties so you don’t have to introduce a whole lot of redundant code. A good example of this is sites I have seen that have a “users” table in the asp.net authentication database then have some other “userinfo” table or something that you have to go do a second query on using the username once the user has logged in, this is bad because first off, it’s a second query and secondly you aren’t looking up the user using a primary key and third, it’s just extra work.
I won’t go into the details of using these two classes and setting up forms authentication there are lots of great blogs about that in the land of Google so I will let you figure that part out however I will tell you that I am using MVC 4 for this and if you user the internet project template it will set all of this up for you except the use of profileBase to create custom properties but again, it’s simple and Google has lots of howto’s on this subject.
Dealing with System.Web.security.Membership
This is the first pain in the ass, it is a static class with all static methods but this one isn’t really that hard to deal with – ProfileBase is a bigger pain because you have to inherit from it and it won’t work unless you implement certain static methods – In order to make Membership unit testable you need to do a few steps that aren’t that hard, just a little laborious. With that said I would like to postulate on the virtues of unit testing and why it is worth a little hard work to make sure your code is tested, essentially it is like this code that is unit tested doesn’t suck – code that doesn’t have unit tests is generally garbage hmm, that is all I have to say about that – Now enough digression, what do we need to do to make Membership testable?
Now that you have that you need to go to whatever classes that are calling any methods from the Membership class and first off – inject it into the ctor and secondly replace the calls with calls to your interface. Lets take an example before I show you some code. Lets say you created an out of the box MVC 4 internet app. There will be an AccountController that doesn’t have a ctor – well of course this means that it has a parameter less one but we all new that. You need to add a constructor that takes an argument and then assigns it to a private variable so you can make use of it, check out the following code snippet.
So you can notice in there I am also injecting an IProfileFactoryService too. I will get to that later. For the moment lets just concentrate on the IStaticMembershipSerivce, lets go look at how I called it.
Fairly simple right – instead of calling Membership.CreateUser I call my service which in production just uses the implementation I created that calls Membership for me, now in my unit tests I can easily mock the call the CreateUser and then verify it was called, which is what this is really all about making sure that our code does what it was supposed to do, i.e. call CreateUser(). So lets look at how I would mock and test this and then how the actual implementation works.
No lets look at the implementation of CreateUser() in my service…
So YES! There is a lot of code in that test and not a lot of code in my implementation – here is the thing, if you are saying “Why would I write twice as much code just to test that little bit of logic”? If that is the case, stop reading and go away please. If on the other hand, this makes sense to you then please – keep on reading.
Dealing with ProfileBase
So dealing with the ProfileBase class is a little harder. ProfilBase is nice because it always you to easily extend properties to users of you system, normally you would just get username and email if you used plain old vanilla .NET form authentication however if you create at class that inherits from ProfileBase you can easily add things like FirstName and LastName etc. Here is a great blog post that tells you all about it, http://weblogs.asp.net/jgalloway/archive/2008/01/19/writing-a-custom-asp-net-profile-class.aspx Real quick, take a look at my UserProfile class I want to have included in some tests.
Of course this becomes a massive pain in the ass when you want to test it because you have to implement GetUserProfile() as a static method otherwise it poops in its pants. Also you can’t mock the properties that you create. This situation caused me a little more frustration but essentially it boils down to the same thing as we did above with the Membership class. You need to once again create an interface and once again, inject it into your class you want to test, standard dependency injection. What confused me is what to do about the properties. There I created a method that in the implementation simply returns the properties for me. Here is the implementation.
Notice the properties? Instead of calling base[“PropertyName”] I use the built in methods SetProperty() and GetProperty(), I could have just as easily used the array like in the UserProfile class. Looking at them with Jetbrains decompiler you can see that in the end the just do that same this base[“SomeProperty”] – shrug – I don’t care. I have a working implementation so now I can test using the interface. So now in order to do that testing it is pretty much the exact same as the test for the account controller.
So yeah - there you go! When you boil it down it seems failry easy to get around this sort of crap but it was a little frustrating fighting with it at first so I thought I would post about it in hopes that someone else can find the information useful.
If you want a good resource on this topic take a look at http://www.manning.com/seemann/ it's a must read if you are into Dependecny Injection and you are serious about being able to create testable software.
Backgound
Basically I wanted to find a clean simple way of making use of and extending Microsofts built in forms authentication. It’s easy to use, relatively secure and can save a lot of time and code, well sort of until you want to unit test. The ProfileBase class is great for extending profiles and adding custom properties so you don’t have to introduce a whole lot of redundant code. A good example of this is sites I have seen that have a “users” table in the asp.net authentication database then have some other “userinfo” table or something that you have to go do a second query on using the username once the user has logged in, this is bad because first off, it’s a second query and secondly you aren’t looking up the user using a primary key and third, it’s just extra work.
I won’t go into the details of using these two classes and setting up forms authentication there are lots of great blogs about that in the land of Google so I will let you figure that part out however I will tell you that I am using MVC 4 for this and if you user the internet project template it will set all of this up for you except the use of profileBase to create custom properties but again, it’s simple and Google has lots of howto’s on this subject.
Dealing with System.Web.security.Membership
This is the first pain in the ass, it is a static class with all static methods but this one isn’t really that hard to deal with – ProfileBase is a bigger pain because you have to inherit from it and it won’t work unless you implement certain static methods – In order to make Membership unit testable you need to do a few steps that aren’t that hard, just a little laborious. With that said I would like to postulate on the virtues of unit testing and why it is worth a little hard work to make sure your code is tested, essentially it is like this code that is unit tested doesn’t suck – code that doesn’t have unit tests is generally garbage hmm, that is all I have to say about that – Now enough digression, what do we need to do to make Membership testable?
- create an interface
- make the classes that call any methods from membership call the interface instead
- implant the interface – this is just a class that calls the static methods for you
- make sure that any classes you modified to use the interface get it injected at the time of construction
Now that you have that you need to go to whatever classes that are calling any methods from the Membership class and first off – inject it into the ctor and secondly replace the calls with calls to your interface. Lets take an example before I show you some code. Lets say you created an out of the box MVC 4 internet app. There will be an AccountController that doesn’t have a ctor – well of course this means that it has a parameter less one but we all new that. You need to add a constructor that takes an argument and then assigns it to a private variable so you can make use of it, check out the following code snippet.
So you can notice in there I am also injecting an IProfileFactoryService too. I will get to that later. For the moment lets just concentrate on the IStaticMembershipSerivce, lets go look at how I called it.
Fairly simple right – instead of calling Membership.CreateUser I call my service which in production just uses the implementation I created that calls Membership for me, now in my unit tests I can easily mock the call the CreateUser and then verify it was called, which is what this is really all about making sure that our code does what it was supposed to do, i.e. call CreateUser(). So lets look at how I would mock and test this and then how the actual implementation works.
No lets look at the implementation of CreateUser() in my service…
So YES! There is a lot of code in that test and not a lot of code in my implementation – here is the thing, if you are saying “Why would I write twice as much code just to test that little bit of logic”? If that is the case, stop reading and go away please. If on the other hand, this makes sense to you then please – keep on reading.
Dealing with ProfileBase
So dealing with the ProfileBase class is a little harder. ProfilBase is nice because it always you to easily extend properties to users of you system, normally you would just get username and email if you used plain old vanilla .NET form authentication however if you create at class that inherits from ProfileBase you can easily add things like FirstName and LastName etc. Here is a great blog post that tells you all about it, http://weblogs.asp.net/jgalloway/archive/2008/01/19/writing-a-custom-asp-net-profile-class.aspx Real quick, take a look at my UserProfile class I want to have included in some tests.
Of course this becomes a massive pain in the ass when you want to test it because you have to implement GetUserProfile() as a static method otherwise it poops in its pants. Also you can’t mock the properties that you create. This situation caused me a little more frustration but essentially it boils down to the same thing as we did above with the Membership class. You need to once again create an interface and once again, inject it into your class you want to test, standard dependency injection. What confused me is what to do about the properties. There I created a method that in the implementation simply returns the properties for me. Here is the implementation.
Notice the properties? Instead of calling base[“PropertyName”] I use the built in methods SetProperty() and GetProperty(), I could have just as easily used the array like in the UserProfile class. Looking at them with Jetbrains decompiler you can see that in the end the just do that same this base[“SomeProperty”] – shrug – I don’t care. I have a working implementation so now I can test using the interface. So now in order to do that testing it is pretty much the exact same as the test for the account controller.
So yeah - there you go! When you boil it down it seems failry easy to get around this sort of crap but it was a little frustrating fighting with it at first so I thought I would post about it in hopes that someone else can find the information useful.
If you want a good resource on this topic take a look at http://www.manning.com/seemann/ it's a must read if you are into Dependecny Injection and you are serious about being able to create testable software.
Comments
Post a Comment