Posted on September 27th, 2009 1 comment
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)
- 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)
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
- Pair programming
And dimensions (characteristics of the products) :
- 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 :
Audience Format Involvment Required material Inspired on … Coding dojo Developers Numeric ++ Computers Martial arts Meetings Developers and business people Open discussion + None None …
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.
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 !
Posted on September 27th, 2009 1 comment
The last BESUG edition consisted in a Silverlight workshop where a Twitter client was built using Visual Studio 2008 and Expression Blend 3.
For those who couldn’t attend the workshop and are interested in that, you can download related ressources here :
Posted on September 9th, 2009 No comments
- The Rise of jQuery, an article explaining why jQuery is so popular
- The jQuery Reference API, a must-have bookmark !
- One single page bringing all jQuery plugins together, sorted by category
- The New York Public Library Style Guide, a collection of acticles about XHTML/CSS best practices
- XHTML 2/HTML 5 Comic Strip
- A collection of Silverlight tutorials
- Hard Rock Cafe Memorabilia, a nice application using the DeepZoom technology of Silverlight
- The CodePlex Silverlight Toolkit, a collection of Silverlight controls with source code and unit tests
- Kaxaml, a lightweight XAML editor
- An impressive article about fluild dynamics in Silverlight
- NerdDinner, a free ASP.NET MVC book
- Webdeveloper extensions for Firefox (french article)
- Ubiquity, a Mozilla Labs experiment using natural language and mashups enabling a faster use of the web
Posted on September 7th, 2009 1 comment
Maintenance cost is a huge part of a software life-cycle (about 70%, according to many sources)
Thus, keeping that in mind when developing is an important thing : it’s your today’s work that greatly influences the future maintenance costs. A lot of good practices have been defined about writing better, cleaner code, with comments, separation of concerns, a right choice of architecture and patterns, etc. The point of this post is not to cover all these points, which are already extensively discussed by many articles on the web but to talk about one less-known but surely not less important aspect : the functional aspect.
The functional aspect, a point our architect Pierre-Emmanuel Dautreppe justifiedly insisted on, consists of writing code that, when read, is just like reading the functional rules that are behind it. Let’s take a simple example :
if (state.Code == 4)
This is the kind of thing we see too often, where developers code to make things work but where other ones (and even themselves some months later) will wonder “what does that mean ?”. One thing you could do is to comment that :
// If we are at the final state, call method "DoSomething()"
if (state.Code == 4)
Obviously, this is not the preferred solution. Even with a less verbose comment, the problem would remain the same. Comments can be handy to explain a bunch of tricky lines of code, but when possible, write good code that is self-descriptive. Indeed, your code would quickly become messy if you need to comment every single line or condition (like the example shown above). Secondly, code is always up to date (because it’s always reflecting the application in its current state) but that’s not the case of comments, which developers sometimes (often ?) forget to keep up to date. And these comment updates have a cost too, needed everytime the code is modified. Let’s look now at our final example :
That’s it ! Isn’t it much better like this ? Of course, we need to add a boolean property to the State class, which can be considered as redundant because the same information can already be accessed via the Code property, even if it’s less clear. We, developers, are used to think about “memory optimization” and such concerns, like thinking twice before adding another variable or property to a given class. But the bigger costs in software development is not the hardware (exceptions kept apart), it’s the human cost behind it. And here was shown a very little example, but just imagine if the project you are working on was written like this…