RSS
Facebook
Twitter

Tuesday, December 28, 2010

Application to install on a new development machine–revisited

As the year draws to its end it’s time to think of the paths we took in the last year…

About 4 months ago I wrote a post titled 14 application to install on a new development machine explaining why I installed each an every application on my new and shiny laptop (T510) I got from work. Since than I’ve installed a few applications, removed some and re-installed a few after finding out I cannot do without them. As an experiment I’ve decided to open “add/remove programs” a.k.a appwiz.cpl and see what has changed.

New arrivals

  1. ĀµTorrent – There is a lot of legal free content out there that is distributed using torrent files this year I’ve used this nifty client to download all of the sessions from conferences I wanted to attend but unfortunately was not able to.
  2. Beyond Compare – You can probably use VS built inn  compare but why suffer?
  3. CCleaner – because windows cannot take care of itself. it always amazes me the amount of junk that this application manages to find and delete (5GB last run). Now with full win7 integration jump list galore.
  4. CDBurnerXP – Small, free, easy to use and does the job – what else could I possibly need from a CD/DVD burning solution?
  5. Google Chrome – It still feels like I’m betraying FireFox but it’s user-friendly, fast and has everything I need.
  6. Git – I’m already using SubVersion for some of my projects but this is the year I’m moving to distributed source control.
  7. Notepad++ – I hate opening Visual Studio to each time I need to edit or view a single XML file. And I haven’t found a programming language that it does not have syntax highlighting for.
  8. PostSharp – AOP in .NET need I say more?
  9. Skype – Helps me to keep in touch with friends an family. I actually use the chat feature more than the voice.
  10. Soluto – “The anti frustration software”. I use it to find and remove the applications that cause my machine startup to take forever.
  11. TeamViewer – I use it for code review when either one of my co-workers or myself are not on site.
  12. Xobni – I find outlooks search lacking in so many places so I’ve decided to install this application. It helps me find the message I’m looking for or the attachment that I’m pretty sure someone has sent me.

Removed

  1. Mozilla Firefox – my long time companion of browsing the web. I’ve used it due to it’s extended support of add-ins but after realizing that I can get the same functionality from Chrome I’ve decided to switch sides. Maybe will meet again in the future – possibly on version 4.
  2. Quicktime – I’m not sure how it got to my machine or what it does there, I could have sworn I already uninstall it several times but it always seems to find it’s way back to may machine. And NO I don’t want to install Safari.

Happy new year – see you in 2011

 

Related Links:

14 application to install on a new development machine

7 free tools for the Hobbyist .NET developer

Five reasons to install Resharper 5 today

nDepend Review

Monday, December 20, 2010

Find out where is the method that was called unexpectedly using fake objects

Every Isolation/Mocking framework out there can verify that a method of a fake object was called and not less important make sure that certain methods are not called.

Let’s say that I want to make sure that a method didn’t encounter any errors during execution but verifying that logger.Error was not called:

[TestFixture]
public class MyClassTests
{
[Test]
public void RunMethod_LogErrorNotInvoked()
{
// Arrange
var fakeLogger = Isolate.Fake.Instance<ILog>();
Isolate.WhenCalled(() => LogManager.GetLogger(typeof(MyClass))).WillReturn(fakeLogger);

// Act
var classUnderTest = new MyClass();
classUnderTest.RunMethod();

// Assert
Isolate.Verify.WasNotCalled(() => fakeLogger.Error(null));
}
}



Note:



Before we continue keep in mind that although I’m using Typemock Isolator the methods explained in this post would (probably) work with any Isolation framework.




Let me explain:




  1. Create a fake logger


  2. Make sure that this logger is returned from LogManager


  3. Create a new class and execute the method


  4. Make sure that Logger.Error was not called



When the test fails we get the following error:



image



It seems that Log.Error was called the only problem is that we have several Log.Error in our code and we can’t tell which of them was called. One solution would be to put break points on each of these calls an run the test using the debugger but we need a more elegant and simple solution.



Exceptions to the rescue



Finding out where the method was called seems a bit over specification – at least that’s what I thought when I was asked by a team member, thinking about this problem I realized that it’s a legitimate request to be able to know where where the calls that caused my test to fail.



A quick solution could be to use the Isolation framework’s exception throwing – when the offending method is called:



[TestFixture]
public class MyClassTests
{
[Test]
public void RunMethod_LogErrorNotInvoked()
{
// Arrange
var fakeLogger = Isolate.Fake.Instance<ILog>();
Isolate.WhenCalled(() => fakeLogger.Error(null)).WillThrow(new Exception("Log.Error was called!"));
Isolate.WhenCalled(() => LogManager.GetLogger(typeof(MyClass))).WillReturn(fakeLogger);

// Act
var classUnderTest = new MyClass();
classUnderTest.RunMethod();

// Assert
Isolate.Verify.WasNotCalled(() => fakeLogger.Error(null));
}
}


I’ve added a call to WillThrow that would happen when the requested method is called.



Running the test shows exactly where the method was called (MyClass.cs, line 6)image



The only “downside” here is that I’m violating the test natural order – a reader expects to find some form of assert/Verify in the test – that’s why I’ve left the call to Verify at the nerd of the test, although it’s not needed because if the test fails it would throw an exception before reaching that line assertion at the end. I found it makes the test “readable” if you state what to expect from the test in code – but if you find it confusing or redundant you can remove it without changing the test.

Wednesday, December 15, 2010

Why you fail with TDD

I’ve been working hard the last six months teaching my teammates about unit testing, code reviews, SOLID, SCRUM and anything else I think we can benefit from. I feel lucky – for the most part they are open minded and accept my ideas and try them without prejudice, working this way has enabled better code and work for both the team and myself.
Over the last months the team’s productivity has increased, the unit tests got a lot better and the code has improved dramatically. But not all is peachy - There is one methodology that I’m having only partial success in convincing my team that they should use – namely Test Driven Development (TDD).
While some of the team use TDD exclusively others still find it too hard and/or cumbersome to use on their daily tasks. I know they’ve tried, and failed using TDD for some of their tasks and now the only reason they keep on trying is because I insist they do it – without real benefits.

Why some fail while others succeed

I wanted to investigate why TDD worked great for some while completely missing the point for others – could it be that the tasks of the developers that used TDD were easier to test? perhaps the developers that didn’t manage to apply TDD worked more with complicated legacy code that was just harder to test?
After much investigation I came to the conclusion that to some extent the success or failure of TDD depends on how easy it is to write tests for that piece of code which is effected heavily from the amount of code existing before the change and how well it was previously tested. But that’s not the whole picture, when I look at the code written by the developers that found TDD to be “just too much work” I almost always see more than one assert which indicates that they might be trying to test too much –and if you write the tests before the code means that it’s a lot harder to do that when you’re actually planning on implementing a few features at once – not very TDD at all…

The TDD way


TDD is not about the tests – it’s about design:
image
By writing the test you actually create a form of specification (singular not plural!) and by making the test pass you satisfy the requirement. By this logic multiple asserts means (more often than not) that you’re implementing multiple requirements at the same time. Another issue with trying to write a test for multiple requirements is that the test tends to be much more complicated than a test that checks only one thing.

One final thought

Multiple asserts is not necessarily a bad things, there might be a valid reason to writing multiple asserts to test a single requirement.
I have a trick to check if a test maps to more than one requirement - ask the developer “what are you testing here”, if he uses “and” in the sentence i.e. “I make sure that the username is valid and an email is send” he might be testing too many things.

Related links:

TDD is more than just writing unit tests
Why TDD is good for testers
The day I understood TDD

Friday, December 10, 2010

Aspect Oriented Programming in Python using Decorators

It always amazes me how some tasks are easier using dynamic languages. AOP (Aspect Oriented Programming) is just one more thing that can be done easily using Python – at least to some extent.
Python has a powerful language feature that makes it all happen – called “Function Decorator” and this is how you use it:

The Decorator patternimage

If I’m forced to “name names” the design pattern used is called “Decorator” and is used to extend a class using composition at runtime.
In simple term I create a class and use it to wrap another class and by doing so I add functionality to it.
So what do it have to do with AOP? simple if I want to add an Aspect to a method I can do it by “decorating” that method with another method. The following code catch and “log” exception from methods:
def decorator(function):
    def inner():
        try:
            return function()
        except:
            print("Exception caught")

    return inner

def someMethod():
    print "someFunction called - going to throw exception"
    raise Exception()

# Run method
decoratedMethod = decorator(someMethod)
decoratedMethod()

It works but something is missing. wrapping a method seems a bit awkward, it’s a good thing that Python has a more elegant solution – decorators.

Enter Python Decorators

Using Decorators is easy – simple add @ with the method/class before the “decorated” method:
def decorator(function):
    def inner():
        try:
            return function()
        except:
            print("Exception caught")

    return inner

@decorator
def someMethod():
    print "someFunction called - going to throw exception"
    raise Exception()

#Run method - look Ma no hands
someMethod()
The code is essentially the same – only now we don’t need to explicitly wrap our method inside the wrapper class.
Using similar method we can add simple aspects to Python methods. if you’re interested in finding more – additional Decorators/Aspects they can be found on Python.org wiki page.
The cool thing is that Decorator’s are available on IronPython as well (just like any other Python feature)– bringing simple AOP to the .NET world.

Happy coding…

Tuesday, December 07, 2010

How to migrate your blog from Community Server to Blogger

Welcome to my new blog – I’ve recently left blogs.microsoft.co.il and Community server and while it wasn’t completely pain-free it wasn’t too hard.

Why

I’ve been contemplating changing my blogging platform for some time now. While I managed to keep on blogging using my previous provider it was becoming more and more of a hassle. The version of Community server used was not updated for at least three years, I kept getting increased amounts of spam and administering my blog was cumbersome.

Another reason was that after a couple of years of blogging I wanted to give my blog a more “personalized” look – new template, my own domain etc. and doing it using the tools I had in hand was impossible. I’ve reached the point that the only thing that kept me there was the amount of effort needed to successfully migrate my blog and more importantly my readers (that’s you) to a new platform

How

The solution to my migration pains presented itself with a new tool called Blog Migrator created by Sean Patterson that was created for blog migration from Community Server to SquareSpace/WordPress, hopefully future versions will support Blogger as well but until then I had to do a small detour:

  1. Migrated the blog to WordPress
  2. Export all of WordPress posts to an WXR file
  3. Used wordpress2blogger conversion utility (thanks Alan)
  4. Imported the result file to blogger

It’s not pretty but it worked – I’ve lost my tags and comments on the way but I now I have a new blog on my domain (i.e. http://blog.drorhelper.com) with a selected template that I can easily customize.

Related Posts Plugin for WordPress, Blogger...