Some stuff about Web and .NET development
RSS icon Email icon Home icon
  • Visug : lightweight stubs & detours for .NET

    Posted on November 11th, 2009 Thibaut 1 comment


    Visug

    Peli De Halleux, a belgian guy now working at Microsoft Research (Redmond) came back in Belgium at the Visug to talk about the project he’s working on. Stubs, Moles and Pex form together a lightweight framework to test .NET applications.

    Stubs

    Stubs is a stubbing framework solely based on delegates. Various examples can be found here.

    Moles

    Here’s an example of what you can accomplish with Moles, allowing you to replace any .NET method :
    Moles

    Pex

    And here, a diagram showing at a high-level view how Pex works :

    Pex

    Pex is an automated whitebox testing tool for .NET. From your code and parameterized unit tests, test code is automatically generated in C# and test results can be seen in the “input/output table”.

    Project-related resources

    I could copy-paste the great description of the project off the official website… But I instead recommend to those of you who are interested in this to take a look at the following resources, explaining you what Stubs, Moles and Pex are all about in the details.

    Pex

    Have a nice reading ;)

    Share/Save/Bookmark

  • Dino Esposito @ Visug : C# 4.0 & testability

    Posted on October 17th, 2009 Thibaut 1 comment

    Visug

    This last 8th of October, Dino Esposito, a very well known figure in the .NET world, came to the Visug to talk about C# 4.0 and testability. Here’s a summary about the session :

    Software testability

    Code should ideally guarantee :

    • Visibility of the current state
    • Control degree at which code allows to send input data for testing purposes
    • Simplicity of the code results in more reliable test results

    Introducing the .NET 4.0 code contracts API

    The ecosystem at a glance

    1. Code contracts library
    2. Rewriter
    3. Static checker
    4. Contract reference generator

    1. Code contracts API

    3 basic types of contracts :

    1. Preconditions
    2. Postconditions
    3. Invariants

    Exposed via the contracts class (System.Diagnostics.Contracts)

    2. Rewriter

    • Translates contracts into code
    • Modifies MSIL instructions to place contracts checks where they logically belong
    • Executable is ccrewriter.exe

    3. Static checker

    • Examines code without executing it and tries to prove that all the contracts are satisfied
    • Lists unproven contracts to fix, otherwise you should debug or cover it with unit tests
    • Detects if there’s a possibility of contract violation

    4. Assembly reference generation

    • Extracts contract information from source code and returns an assembly with contract-only information
    • Used by rewriter & static checker
    • Executable is ccrefgen.exe

    Steps of a method

    1. Check validity of parameters & stats
    2. Do real work
    3. Check of existing works
    4. Update state accordingly

    Set up

    1. Add reference to mscorlib
    2. Contract must be specified in the body of the methods
    3. Contracts are not mandatory. You can do without

    Preconditions, postconditions and invariants

    Preconditions

    • Requires(bool condition)
    • Requires<TException>(bool condition) throws an exception if condition is not met
    • if-then-throw statements
    • RequiresAlways(bool condition) is like Requires but stripped off in retail builds

    Postconditions

    • Ensures(bool condition), condition must be true at the end of the method
    • EnsuresOnThrow<TException>(bool condition), condition must be true if exception is thrown. Allows for checks even if exceptional return arises (network error, stack overflow, …)
    • Helper methods
      • Result<T>()
      • OldValue<T>(T variable)
      • ValueAtReturn<T>(out T variable)

    Invariants

    • Invariant(bool condition), object-wide condition that must hold for the lifetime of the class
    • All invariants for a class are defined in one place

    Best practice :

    • Define invariants before implementing the class
    • Express the conditions under which the object is in good state
    • Could be hard to add them at a later time

    Assert & assume

    • At runtime, fully equivalent to Debug.Assert
    • Static checker attemps to prove any Assert, emitting a warning if it fails
    • Static checker treats Assume as always true, adds the assumption to its collection of facts

    Quantifiers

    • Used to iterate a check on all elements of a list
    • ForAll(…), true if condition is met by all elements
    • Exists(…)

    Interface contracts

    • Define a separate class for the contract because we can’t add code to interface memebers (no mixins in C#)
    • Link to the interface via attribute

    Contracts & inheritance

    Contracts are inherited by derived classes, regardless wether you invoke base class methods in overrides

    Code contracts & debugging

    • When failure, contract raises
      • ContractFailedException
      • ContractFailedEventArgs
    • No default handler (thrown everytime)
    • Register handler to ContractFailedException at startup (Global.asax for ASP.NET, Main method for WinForms)

    Contract failures & unit tests

    • You don’t want contract exceptions in unit tests
    • Rather want exceptions to be reported as tests failures
    • SetHandled() to let assume exception has been handled and SetUnwind() to clear the stack

    Summary

    • Code contracts as part of the design effort
    • Adds testability to classes & code
    • New API coming up in C# 4.0

    And one final important quote of Dino Esposito :

    “Testable code means that it exposes every significant part of it in order to check its correct behaviour”

    See you next time ;)

    Share/Save/Bookmark

  • Visug : Mocking

    Posted on May 9th, 2009 Thibaut 1 comment

      

    The last session of the Visug, held at RealDolmen and presented by Maarten Balliauw concerned Mocking. Here’s an overview of the presentation that was given :

    • Unit testing
    • Dependencies
    • Mocking

    Part #1 : Unit testing

    Impossible to talk about mocks without mentioning TDD (test driven development). Indeed, mocking is all about unit testing. Unit tests should be :

    • Self validating (validate themselves against some behaviour or return values)
    • Fast (you don’t want too long for them to complete)
    • Focus on a method or functionality (atomicity of testing)
    • Isolated (from one another)

    One of the most famous style of unit testing is the AAA. Below some code example illustrating this :

    /// <summary>

    /// Tests a booking when there is no more rooms

    /// </summary>

    [TestMethod]

    public void Restaurant_InsufficiantRoomsTest()

    {

        // Arrange : prepare your variables and everything needed

        Table table = new Table(5);

     

        // Act : execute code

        table.Book();

     

        // Assert : check the values or behaviour

        Assert.IsFalse(table.IsAvailable);

    }

    After this introduction, Maarten started some live coding, remembering us that writing unit tests is the first step before coding. You place yourself as client of your future code and see what you’d expect from it. Then, you code it. A little productivity hint : use the Generate Method Stub option from Visual Studio on the methods you haven’t implemented yet (as you code the test first, it won’t compile until you actually implement what you’re testing).

    Generate Method Stub

    Note : code samples illustrated here are from me, the speaker is thus not responsible for eventual errors they would contain.

    Part #2 : Dependencies

    Let’s introduce dependencies now. The example that Maarten coded was a bar tender and depending on the weather (web service call), some cheese (sunny) or nuts (rainy) were served with your beer. The problem here is quite evident : how can you test that in the more isolated way possible in order to keep control of your tests ? Indeed, you need to kinda “force” the weather to sunny or rainy to check if your system is implemented properly and delivers the expected behaviour.

    To do this, several “stunt double” solutions are offered to you :

    • Dummy (eg : null, empty list)
    • Fake (a working implementation)
    • Stubs (implementation using canned answers)
    • Mocks (implementation returning expected answers)

    Through some live coding again, Maarten showed us how it’s tedious, time consuming to implement fake objects and how unclean it is (classes need to be duplicated for fakes).

    Part #3 : Mocking

    Mocking frameworks are a convenient interface for setting up fakes/stubs/mocks. They do the job is less code, in AAA style. Some of the more popular mocking frameworks are :

    • One of the most mature and feature complete mocking framework
    • Uses Castle remoting for mocking calls
    • Open source
    • Free
    • This is the framework we’re using at work and we are very satisfied of it

    • Mature and fully featured
    • Isolates IL generation
    • Not free

    • “New kid”, increased popularity
    • Uses castle remoting
    • Not feature complete but in development
    • Open source

    Maarten then continued some live coding to illustrate how to use Moq. First, you gotta mock the object you want to fake functionality :

    var ws = new Mock<IWeatherService>();

    Then, declare what you expect from methods :

    ws.Setup(s => s.WhatsTheWeather()).Returns("sunny");

    Some interesting points (some are general about mocking frameworks) :

    • Expected exceptions throws can be verified
    • Callbacks can be made, instead of returning a particular value
    • Protected members can be mocked
    • Mocking can be recursive (XML tree generation for example). Prevents you from writing giant stubs
    • Verify calls to expectations : ws.VerifyAll();

    When should I mock ?

    • External object (web service, DB, …)
    • Non-deterministic objects (temperature, time, …)
    • Hard to reproduce situations (simulate a network error, HDD out of space, …)
    • Slow execution (simulate long calculations)
    • When some objects are not implemented (”empty shell”)

    And to finish this post, some recommendations :

    • Don’t mock everything ! Use it when needed…
    • Use loosely coupled code, it greatly eases the TDD (test driven development)
    • Tie everything together using IoC

    See you next time ;)

    - Thibaut

    Share/Save/Bookmark