I am not a sharepoint manIâm a unit testnig man. Iâm going to show you examples, from real life codeHow many people do unit tests? Use isolation frameworkSo letâs talk about me.
My Tank storyI couldnât test parts of the system separately, and thatâs what unit testing is about. If I could, it will not take 3 months till the next test, and I would know if my fixes were correct (they weâre not).
How do you do unit testingHow is the SharePoint world different (or similar) to the rest of the world
Testing units of the software, without the restSimple, but not easily achievable.Software is already kvetched together from the get go.And SharePoint is a 3rd party which we donât have control over. We cannot disconnect from the server.
My team was always fighting over because of broken builds.My testers did not trust the devs.As a manager, I had to deal with that. Oh the headache.Two questions: How do you know your stuff works?How do you know you havenât broken anything?And then comes magicPeople are not afraid to make changes to their codeYou know exactly what failedIt takes a lot less time to debugNo more stupid bugzIt makes you THINK about the code youâre writing.It makes you a professional â you are responsible to test your code, not QA
Moment of Hebrew:Unit testing = Automated unit testing.When I started at Bio-Rad (1997) the first thing they taught me was unit testing. Manual.VB Form, for a C++ COM componnet.This is not repeatable.When I changed my code, I did not go through all the scenarios Iâve already tested.And when you fix a bug, in a component written 6 months ago, would you even remember? No.Unit tests help you remember, and remind you.When something breaks, youâll know immediately. The sooner the better. And mostly, thatâs what automated unit tests do. They shorten the feedback cycle from weeks and months to seconds and minutes. Itâs easier to fix something that you just wrote.And this is key: unit tests should run quickly. If they donât the vicious cycle begins: No quick feedback, less test runs. Then why should I write tests if I donât run them, and the road to hell is now paved.
Letâs take a look at the environment.First we need a framework. We need to say â this is a test, and thatâs the criteria for pass/fail.Then you need a runner, and result view.MSTest (yes, thereâs NUnit, but you donât need it).Show logic of webpartCreate a new projectAdd referenceShow attributesWrite //AAARename testWrite testRun test.Notice weâre testing logic.In the real world, itâs not that easy.
Code is not testable by default.All kind of tutorials, donât prepare you for testability. They give you unstructured code. This has changed about a year ago with P&P promoting unit tests.Who knows what P&P is?Itâs still not enough. Weâll go into MS ambivalent relations with unit testing later.Who is using SP 2010? Some improvement there since 2008.The F5 Build/Deploy/ Test cycle is slow. It takes minutes. Slowness, kills unit tests.Speaking of which, who uses a virtual environment for development? Itâs slow by nature.
SharePoint is the example I use for dependency problem.For the case I showed in my webpart, I need to set up differnet SharePoint setups.Imagine how many I setups Iâll need to test every scenario in the application? How long it will take them to run?Will I do it? Will you do it?No. The problem, is that SharePoint is a dependency, and itâs a problem to get rid of.Because SharePoint objects donât lend themselves for simulations.They have private consttructors. Cannot inject them directly or through Dis.They are sealed and cannot be overridden. These are the two major ways to change behavior.
Weâll see about that in the next session.
Dependencies is why most people stop doing unit testing.Overriding dependencies is hard.
Let you change the behavior of your code, without changing it. (mostly)Basically, isolation frameworks allow you to do 2 thing by creating fake objects.
This is important: Without changing my production code.
The Asserts I showed you before test state: properties, fields.What happens if I want to make sure a method was called with the correct arguments?Like database connect?With SharePoint its worse, because most of the object model is designed for reading, not building it..
For the SharePoint crowd, there are currently two options: Typemock Isolator and Microsoft Moles.Iâll show you examples for both.Isolator was until recenty the only way to test SharePoint. Thatâs because it can fake any type â statics, sealed, you name it. P&P said so.Microsoft is between two places: the P&P says do unit tests. But the SharePoint team doesnât do it themselves., and produce something not testable.What did they do?Moles was until 3 months ago a research project, part of the Pex project. It is now a power tool. This means most people donât even know it exists. MS doesnât want to push unit testing.So Iâm going to show you how tests look like in both cases. Iâm not going to do all the process. I want to give you a feeling on how tests looks like with SharePoint.Example 1: Webpart.Isolator References APIsMoles Lambdas
CostBoth can fake everything.Isolator is easier to write/readMoles doesnât have a verify.With Moles you really need to know your lambdas. Itâs painful.Isolator has more features, more functionality. It is a decidedly unit testing toolMicrosoft is not pushing it â hard to find examples on the net. 1 man show.And besides, weâre smarter and better looking.
Which ever tool you use you need to understand, that you need a tool.Stupid bugz.You can start by downloading Isolator and Moles. Start writing unit tests.