Visug : lightweight stubs & detours for .NET

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 :

Pex

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

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.

Have a nice reading

Dino Esposito @ Visug : C# 4.0 & testability

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

ReMIX 09 @ Brussels : Summary

This last 29th of September was organized at Kinepolis Brussels the 2009 edition of the ReMIX, which is a one-day summary of the MIX edition (held last March in Las Vegas).

Two session tracks were available : the Web developer track and User Experience (UX) track. But before this, an introduction was given by some well-known people of Microsoft belgium.

Introduction

By Luc Van de Velde, Katrien De Graeve, Gill Cleeren, …

Here are some key points of the presentation :

• A demo of the Microsoft Web Platform Installer by Katrien De Grave. More info on her blog post about it
• Demos of Silverlight 3 new features : smooth streaming, rich media capabilities, SEO & deep linking, improved performance, …
• Zendster, the first belgian web hoster to provide smooth streaming for Silverlight
• Companies (such as Elia) performing demos about their Silverlight apps for critical, line-of-business applications
• A demo of SketchFlow by Arturo Toledo
• Interviews of companies reflecting the important shift towards UX, which is given more and more importance
• VTM news (a dutch television company) is using Surface, manipulating a newspaper as a support for presenting news but also to present election results
  
  
• A demo of the Surface application of Belgian Beer Cafe, featuring a wonderful background simulating beer liquid and providing infos about the beers you put on the table. Check out the video below :
  
• The launch of WebsiteSpark, an Microsoft initiative for providing training, free licences for small companies, etc

Session #1 : Prototyping with Sketchflow

User Experience (UX) track
By Arturo Toledo

• No slides, live demo of prototyping an app using SketchFlow
• More than a mockup tool, SketchFlow allows you to make it behave a real app (and used as is)
• Effects, such as transitions, can directly be set easily in SketchFlow. No need to code to get everything working (although you can write some if you want to fine-tune some stuff)
• The user (typically the customer) can test his app mockup as it’s a classic Silverlight application
• Comments can be drawn on the mockups or feedback can be written in a column next to the mockup screens
  
  
• The flow of the application can be designed visually, creating transitions by linking nodes representing pages
  
  
• The creation of datasources is very easy in SketchFlow. Indeed, in a typical mockup, you need to create dummy data (lorem ipsum for texts, fake names or numbers for forms or grids, etc). Such data can be autogenerated by defining the type of data we want (ex: price, date, text, …), which is a great save of time

Session #2 : Building Amazing Business Applications with Silverlight and RIA Services

Web developer track
By Brad Abrams

According to Brad Abrams, the must-haves for a great app is :

1. Professional feel
2. Rich data query
3. Validating data update
4. Authentication
5. Different views (of the same data)

• A little Silverlight application was built in a RAD fashion using Entity Framework, featuring a GridView, a form to add/update/edit values and Regex attributes on the properties (code behind) for validations
• A SiteMap of the app was provided in Robots.txt for indexing by search engines. Different views (html pages) were provided for search engines bots to parse the content of the application

Session #3 : Creating Silverlight Experiences with Blend 3

User Experience (UX) track
By Arturo Toledo

• An Adobe Illustrator file was imported in Expression Design (a character in a spaceship)
• Showed then how to build a custom control (a button with glossy effects, mouseover growing animation effect without coding, …)
• Custom button fires an event, starting a storyboard to make the spaceship fly on the screen
• Timeline manipulations are performed to make the spaceship make a U-turn before flying back to its original position

Session #4 : ASP.NET MVC Wisdom : building a real-world app in 60′

Web developer track
By Maarten Balliauw

This session covered the following points in ASP.NET MVC :

• Validation
• Templated helpers
• Security
• Routing

Slides of the presentation are available below and source code here

Conclusion

A very interesting event as you can tell, providing lots of news, demos and other stuff about RIA development in general. See you next year

Visug : framework design guidelines

The last Visug session was presented by Brad Abrams, Program Manager on the .NET Framework team at Microsoft, who shared with us guidelines about framework design. Member of the .NET Framework team since the beginning, his experience in the field is very valuable for architects and software designers, but also for developers who can highly benefit from a lot of good practices.

Below, you can find slides of the presentation :

Have a nice reading

CITCON 09 @ Paris : summary

Some days ago was held the 2009 edition of the CITCON (Continuous Integration & Testing Conference) at Paris. As my colleages and I are working on a project using the eXtreme Programming methodology, we are always eager to share our experience and learn from others. Below is given a summary of this edition.

The principle of organization

For those who never went there, here’s an introduction about the principle : the first day, from 6pm to 9pm, everybody introduces himself and then everyone who wants to be speaker has to “sell” his topic to the public. A post-it is for each topic put on a shedule board and people vote for the ones they like. The day after, only the topics with most votes remain (similar subjects are often merged) and then people can choose which session that want to attend. A session is about 1 hour long and is very interactive : everybody can talk and share his experience. In total, 5 sessions are organized : 2 in the morning and 3 in the afternoon.

Session #1 : Testing & “done”

The purpose of this session, animated by our architect Pierre-Emmanuel Dautreppe, is to discuss about what to test and how (database, UI, everything) and when you consider your testing done. Here are some key elements of the discussion :

• Cannot test everything
• Test to limit the risks of the application
• Ask the customer how he expects his application to behave. Then, write user stories accordingly (test cases)

Done ?

• Tested every user story in the app (at least the main ones)
• For some people, it’s only about code coverage (ex : 80%)
• Having generated enough information reflecting the quality of the product (test results as a control panel)
• Tested every part of the API
• When confident on the product quality (= ready to be shipped)

Session #2 : Mock objects

When to mock ? (cf VISUG session about Mocking)

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

Other advices :

• Try to mock the minimum possible
• Some mocking frameworks allow to mock without coding interfaces (less need to code the application following the testing framework behind it)

Session #3

Developers & business people collaboration

• Too often, business people are too far away from the implementation
• A close contact should be kept with the customer. In the context of acceptance testing, it’s useful to define user stories
• Important to make the project beneficiate from the knowledge of business people

Top 5 reasons why teams fail with acceptance testing

• No collaboration
• Focusing on how and not on what
• Tests unusable as live documentation
• Expecting tests to be a full regression suite
• Focusing on tools

Session #4 : putting Selenium in its place

Selenium is a web application testing system that enables you to record operations (while you manipulate the browser) and generate code in multiple languages (C#, Java, Ruby, …). You can watch a quick demonstration on the official website.

After this introduction, one of the big cons of this approach (and also code-based approaches) was underlined : when the front-end changes, a lot of acceptance tests fail. Indeed, suppose that you have many tests for a single page (to cover different scenarios for example), if you change one thing, everything might fail. The point here was to propose a solution to this problem, abstracting common operations into activities.

Activities are blocks of code, enabling top abstractions of recurrent actions on a web page. Thus, if something changes on your front-end, you modify one activity and not a whole bunch of tests. Unfortunately, no examples were given but you should get the idea anyway.

Session #5 : 100 agile learning ideas

This fifth and last session was more than a discussion, it was actually a little workshop where everyone had to imagine new learning ideas about the agile methodology. The approach was the following : we have products :

• Coding dojo
• Meetings
• Pair programming
• …

And dimensions (characteristics of the products) :

• Audience
• Format
• Involvment
• Required material
• Inspired on
• …

In fact, the audience was split in 2 teams. The first one had to find products and the second one dimensions. A matrix such as this one was then built :

After that, everybody was assigned a random value in each column and had to imagine what product could be created from that. For example, I got :

• Audience : developers
• Format : team
• Inspired on : martial arts
• Involvment : +++
• Support : computers

And created Best Pair, a situation where 2 developers are given conflicting instructions (such as opposing implementation alternatives) and must develop accordingly. The informations given are related to the same goal, but developers are not informed about that. They must communicate, keep their self-control (martial-arts inspired) to face the conflict and reach an agreement. The point here is to learn to work towards the same goal without staying blocked too long on concerns such implementation details. If the developers success in developing the application and resolve the conflict in a limited, pre-defined amount of time (ex : 1 hour), the exercise will be a success.

Conclusion

This was my first CITCON and found it interesting and original at the same time. The fact that participants are speakers at the same time enable rich discussions and return of experiences. Definitely not an event to miss if you’re working with (or interested in) agile methodologies !