Isolator for Sharepoint : Unit testing for sharepoint made easier

In one of the blogs I'm reading found that there's a new product for unit testing SharePoint without running Sharepoint instance. Well, that is nice.


And here's the adverticement:


Typemock are offering their new product for unit testing SharePoint called Isolator For SharePoint, for a special introduction price. it is the only tool that allows you to unit test SharePoint without a SharePoint server. To learn more click here.

The first 50 bloggers who blog this text in their blog and tell us about it, will get a Full Isolator license, Free. for rules and info click here.

Gues what does it mean?

Gues how can 1 not be equal to 1?

Failures:
1) SourceGrid.Tests.TestRangeData.WriteData_FromSourceGridToSourceGrid : 
 expected: <1>
  but was: <1>
   at SourceGrid.Tests.TestRangeData.WriteData_FromSourceGridToSourceGrid() in e:\Projects\csharpexamples\SourceGrid\trunk\SourceGrid4\SourceGrid.Tests\TestRangeData.cs:line 122

p.s.
And yes, it is not the case when one one is string, another one is int

Web application unit testing

How to test applications on .Net

The thing that popped into my mind is "User Interface testing is not stable". Period.

Any time I tried to test user interface, everything ended up in recycle bin next week, if not next day. If you want to tage huge advantage of unit testing your code, you must write it clean and separated. That's true both for web and desktop applications.

If you ask what is clean and separated code I would describe it like this: your code must be written in as small chunks as possible. Your functions should only one single thing, your classess should have only one responsibility, your namespaces should be grouped by behaviour.

It's like in orchestra - if you have a violin, a guitar and a maestro, then you have three responsibilities - play violion, play guitar and act as a maestro.

If you happen to write a Web application, do not follow blind examples of putting together your data loading, decision and presentation logic into one single code-behind (or whatever) class. It's allways the same three letters - Model / View / Controller - MVC.

It's as important to separate M from C, as to P from M and C. Your presentation can NEVER be together with your controllers. Clean separation is both a prerequisite for unit testing, and a result of it.

Web unit testing could check your model and controller classes. hammet, maintainer of Castle Project also tests ViewComponents.

As for unit testing tools, one of the more popular are watin and Selenium. You also check my presentation about selenium: pdf format odp format

Decomposing systems

Today I begin decomposing our system into separate components. I felt that I will have to do it sometime, but I was reluctant to do it because I never did it before.

What I learned thinking about decomposition is this:

• Never postpone things you have to do. Always remember - You have to do what you have to do.


• Castle.Windsor is great.
  

  
  Castle.Windsor is a IoC container (Inversion of Control), which helps build system from small components. I found it to be very simple, and easy to use.
  
  Now, as I have moved all generic controls and helper stuff from UI to Core, and concrete stuff from Core to UI, ia have 50 tests not running.
  
  Probably, most of them are ActiveRecord.InitializationExceptions, but anyway, unit tests again help me make good pace without worrying of damaging my system
  
  
  

  
  

The best part of Unit Testing

The best part of unit testing is that it gives confidence that the code is yet again maintanable!

Sadly, but my code is falling apart just at the moment. The parts that worked before are not working for some mysterious reasons. And the worst thing is that i discover those bugs by sheer accident!

I mean - there's no testers in our team. And there's no way the bugs can be found when they bring up, except unit testing.

When i write a unit test, i feel a very strong feeling, that my code is secured from future bugs, which pop out unnoticably. It gives me confidence, and allows me to further refactor and expand the system

Unit testing is leaking into me slowly but constantly

Finally I start to embrace test-driven-development.

Whenether I fix a non-trivial defect, I first write a unit test to catch that error, and then fix the bug.

Even now, for example, I have to create a new command which creates a new contract for each student. Instead of writing immediatelly whole working code, I make a sketch of what my working code might look like, then I write unit test to test that my sketch code does not work.

Finally, (in a few minutes or hours) i implement the feature and the tests pass. Then I run all my tests (64 right now), and commit the code to svn.

That's my life.