Two years ago, I have started to work with the TFS and so with MsBuild and Continuous Integration. I have soon seen that I was missing some automation tasks and so I turned to SDC (.NET SDC Solution Build & Deployment Process & Tools) that was adding more or less 100 new tasks. More than enough !
Yes but in the end I was still missing some specific task and so I have started to create my owns. Here is how Jarod.Sdc.Extensions project is born ! I have decided to create a package around .NET SDC (migrated after a while to SBF - Solution Build Framework) and to create my tasks.
Here is the latest version of this library including a new task : MsTest. Redundant with the Microsoft's TestToolTask or SBF's MsTest task ?
No not really. First it allow you to work more low-level by playing directly with command lines MsTest launching, and then it allows you to "ignore Inconclusive tests".
The reason why ? In our environment, business analysts are describing or coding tests weeks or months in advance specifying for which version they will have to bi in application. To avoid loosing them or having difficulties to find them back, we don't want to use the Ignore attribute. So what ? We say they are inconclusive. (Note that we have "only" the Team Edition For Software Developpers, and so in the 2005 version, no test list manager is available).
What is the consequence, we have "ad vitam eternam" a red build because we always have some inconclusive tests. In our specific case, this is the only case we have inconclusive tests.
So this new task allow to consider that all the inconclusive tests will be passed. You will still see the good result in the test run (seeing passed and inconclusive tests) but your global build will turn green if it contains only passed tests or passed and inconclusive tests.
This task supports Visual Studio 2005 and Visual Studio 2008.
Want to have a try ? Find it here !
Note that this version has been released almost one month ago but I didn't got time to communicate sooner...
 |
|
I have been writing a very small introduction to the CITCON in this post
The conference is now finished and so it's time to speak a bit about it !
This edition was full of surprises for me. First because it's the first time I was going to CITCON (pronounce it "KIT-KON") and the first time I was participating in Open Space discussion. The principle ? Simple. No conference, nothing really planned in advance.
On friday evening, after every one (between 60 and 100 persons) has presented themselves in a few words, some people started to explain the subjects they would like to discuss about. All could propose a subject and all could vote for their favorite subject in order to plan after how the different talks will occur on the next day and in which room. Interesting concept. In the end CITCON is really an excahnge of point of views, good and bad experiences, between people that all have the same goals : learning and sharing.
|
 |
Second surprise : I won a book. Nice. I never win to lotteries I participate into, but I win in lotteries I don't participate in ! 
It will probably be an interesting reading.
You want to see more of this book ? You can go to see it on Amazon
|
|
But let's come back to the discussions I have participated into.
-
At 10h00 : Discussions about the "Build pipeline" with maybe 30 participants, or how, why and which difficulties shall we encounter, to provide an automated build from development to automated test platform, QA platform and production platform. We have been discussing how recent is the technology, and so how "immature" or "not yet ready" are people from Operations. I specially liked the discussion and point of view of Xavier Quesada Allue about database update.
-
At 11h15, Jeffrey Fredrick (one of the organizer of the CITCON) has presented Crap4J, a new utility used for Java to determine where "crap is". By "crap", you should hear "risk", as this acronym means "Change Risk Analysis Prediction". How it works ? Putting in common the cyclomatic complexity and the code coverage to see the most potential risk in code.
-
At 14h00, Alexander Snaps had organized a small talk about "Code Reviews and Delayed Commits". This discussion involved a few people only among Dario Garcia Coder, Andrew Binstock, Patrick Smith and myself. It was for me, without any comparison, the most interesting discussion (maybe also because it was with much less people) with some opposite point of views. Shall we - or not - make code reviews before commits? If yes, on wich criteria shall we do them? Is it possible to ask the developpers to commit anyway (in a separate repository ?) and ask a code review later on ?
-
At 15h15, Douglas Squirrel wanted to share with us its idea of creating a new software : "Karma for Continuous Integration". Its goal ? Attributing (or removing) "Karma points" to developpers based on the commit he has just done (has he incresed te code coverage, decrease the complexity, ...). He wanted during this session to explain its idea and see what would be the people expectations about such an idea
-
And finally at 16h30, Bernard Vander Beken and Alexander Snaps wanted to speak about the Web UI Testing problematic. In the end we have spoken about some tools, possible limitations, how to test Ajax based application, should we go until "mocking up" the server itself ? Interesting talk wth the expertise of the google guys showing of what they have done.
What can I say more ? Well I just hope to continue the discussions with some of you guys and to be present in the next year session !
I will probably update soon this post to add some link to other interesting people I have met there !
|
My team and I are working for two years on a big XP project now. Among the 8 developpers, we can find all the levels and all the educations. Some are engineers - for which IT is their first choice - and some were doing another job and have decided to switch direction.
Of course this does not mean that a kind of developper is better than another one, but this mean that we all have a different approach to a same problem, a different point of view, interpretation and understanding, depending of our experience, meaning habits, past and education.
Most of us had not done XP before this project, meaning that we had learned the methodology progressively and we have started to own it and to "customize" it to our needs.
For some of the group, XP has oftenly been considered as an excuse to do less. I mean I encounter people saying "No we shouldn't do that, because XP is iterative and so we should do only what we need for now. Let's do it simple, not more".
Said like that, it seems to be fully correct. Nevertheless, there is a huge misunderstanding behind this word of "simple".
Are we speaking of "simple code" or of "simpler solution" ?
There seem not to be any difference but it's huge and will drive all the future development. We could turn this question in another one - as it is in my view to exact ending of it - shall we throw the code in the future or shall we make it evolve ?
I have regulrarly fought during these 3 years to say : "simple do not mean to write very basic (too basic) code. So simple that this code will be thrown away in the next iteration because it is too simple (understand too low level, too concrete, without any level abstraction raised) to evolve".
I'm now reading the book "Extreme.NET" by Neil Roodyn. Not a very recent one so the .NET part is a bit outdated but the "philosophical part" is still very accurated.
There is a very nice sentence in it that, in my view, summarize all this to give a simple answer ;-)
And by "simple" here, I mean an answer that should be able to make all developpers think about themselves and what they produce.
"Simple does not mean easy. Developpers who are starting out often misinterpret this as "Do the easiest thing you can possibly do." [Pierre-Emmanuel Dautreppe's note : I would even say : "Do the more stupid thing you can"] This is incorrect; simple is often a lot harder to achieve than complicated. [...] The switch statement is easier to write, but the polymorphism provides a simpler solution."
A "simple solution" means a clear and open solution, a solution that will be simple to make evolve, that won't be reluctant to changes.
At the same time, Roy Osherove speaks about unit testing and call them TATs or TTLs, meaning "Throw-Away Tests" and "Tests That Lasts". For sure, it's a point that should make all of us think about our work.
For sure, I will come back often to this point in the future.
| |
|
CITCON (Continuous Integration & Testing Conference) comes to Brussels in October 19th & 20th (friday evening and saturday).
Interested in 1-day of great conference about CI and testing ? Join me there !
Be careful, it's limited to the first 100 subscribee so hurry up.
Need more information about CITCON ? Visit their website dedicated to Brussels !
|
A few days ago, we have made an XP meeting in the company to let all people in the team (developper, analyst, tester, ...) express their feeling, what was working good or less good, what we should impoove, ...
And one developper has said that. For him, in XP, "each developper must have its own bottle of water".
I will try here to reformulate (and translate) what he has said.
"For me, in XP and in pair-programming, it's important that each developper has its own bottle of water.
A few years ago, I was working with handicaped people and we have done an exercise one day, asking to valid people to seat on the wheel-chair and so be at the place of handicaped people. One assistant/helper was doing what he has always done with handicaped people, pushing them in the house. What was happening ? At the first turn, the assistant turned in one direction as he has always done, and the "fake handicaped" was so surprised as he was expecting the turn. Later on, arrival on stairs and starting to climb them. The guy was simply astonished and afraid.
Let's stop the exercise, and do it again, differently, asking to the helper to always speak and explain what he was doing before doing it.
Now we will turn to the right. The "handicaped" guy was of course not surprised. Let's now climb the stairs. Ok no problem.
What's the point of that ? When you speak and explain what you do, or what you want to do, the other guy is never lost and can follow you easily without any surprise and without any fear.
And the parallel with Pair-programming ? Of course we won't compare one of the two developpers with being handicaped, but one of the two is not typing and thus doesn't know the minds of the writer and can be surprised (and easily lost) by what is colleague is now doing.
To avoid this kind of situation, it's important to have each people in the programmer pair speaking a lot of what they are currently doing and their idea, what is their goal, how to achieve it. It will lead to a good cohesion between each developper and the team will be more concentated and efficient.
Of course, as we must all speak a lot, we'll get thirsty and so, we each need our own bottle of water."
I find this example quite interesting because it represent the feeling that the copilot is having sometimes, not knowing where the pilot wants to go. So let's all speak more ! (in a productive way!)