|
|
We are proud to announce that a pre-release of GreenPepper for C++ developers is available! This release supports both Atlassian Confluence and XWiki wikis.
So C++ comes today to enhance the existing list of software development platforms supported by GreenPepper (Java, PHP, .NET, Ruby). This pre-release has been developped in 2 months in C++ using full test-driven approach thanks to the GoogleTest framework.
Compiled langages (like C++) are pretty challenging regarding the lack of mechanism like runtime type informations (or reflection). Our team took the challenge and got inspired by the same solutions as those retained by Google.
Our team hid complexity as much as possible, to allow GreenPepper C++ users to program with a simple source code (hum… although “simple” with C++ does not mean the same with other langages  )
Want to see what a fixture source code looks like? Below a C++ header file sample :
| CalculatorFixture.h
using namespace greenpepper;
using namespace type;
CLASS_FIXTURE_BEGIN(CalculatorFixture)
public:
CalculatorFixture(void);
IntegerType a;
IntegerType b;
void setA(IntegerType a);
void setB(IntegerType b);
IntegerType getA();
IntegerType getB();
IntegerType sum();
REGISTER_METHODS_BEGIN()
REGISTER_PROCEDURE_1(setA, IntegerType)
REGISTER_PROCEDURE_1(setB, IntegerType)
REGISTER_METHOD_0(getA, IntegerType)
REGISTER_METHOD_0(getB, IntegerType)
REGISTER_METHOD_0(sum, IntegerType)
REGISTER_METHODS_END()
CLASS_FIXTURE_END(CalculatorFixture) |
If you want to start using executable specifications within you C++ projects, just tell us! Please contact us at grenoble@greenpeppersoftware.com. Download the package here.
Kind regards.
As you may have noticed in the Executable Specification and build integration post, build system integration is an area where GreenPepper shines. Most teams having good automated build practices also use a continuous integration (CI) server. We provide more comfort to those teams by allowing them to look at their GreenPepper execution results directly from their CI server user interface, we have developed integration with two major CI servers: Bamboo and Hudson.
Bamboo Build View :
Hudson Build View :
If you would like us to develop an integration with your favourite CI server, let us know.
This new release includes a new plugin for Hudson (a continuous integration server), support for Jira4, a better use of accented characters in specifications, many improvements to the core and much more…
See the release notes for more details…
Éric Laramée, a colleague at Pyxis the other day was recalling the Greed is good scene from the movie Wall Street
The point is, ladies and gentleman, that greed, for lack of a better word, is good. Greed is right, greed works. Greed clarifies, cuts through, and captures the essence of the evolutionary spirit. Greed, in all of its forms; greed for life, for money, for love, knowledge has marked the upward surge of mankind. And greed, you mark my words, will not only save Teldar Paper, but that other malfunctioning corporation called the USA.
Thank you very much.
We the started to play with that quote and here is the result:
The point is, ladies and gentleman, that green, for lack of a better word, is good. Green is right, green works. Green clarifies, cuts through, and captures the essence of the evolutionary design. Green, in all of its forms; green for life, for money, for love, knowledge has marked the upward surge of mankind. And green, you mark my words, will not only save your project, but that malfunctioning industry called IT.
Thank you very much.
We had a good laugh and thought it was very cool!
Some developers are asking me : How do I tag my specification when I do a release or close a development branch while GreenPepper does not provide full SCM capabilities in the wiki.
I explained in Why we did not implement a full SCM for specifications why we did not think it was a good idea to implement full SCM capabilities in the wiki.
To achieve the need stated above, we have implemented in all our build system integrations (Maven, MSBuild and Nant) a feature called freeze, what this does is simply going to the wiki server to get the specifications and store them locally. See the documentation to learn what you need to do in your build script.
You simply commit those files and tag them with your source files. Couldn’t be simpler!
Life is Green!
You can even come back months after the release and execute the specifications locally from your IDE or from the command line.
Life is Greener!
In the Executable Specification and Build Integration post, I explain how GreenPepper supports the full development cycles. Some people sometimes ask me why we do not have full SCM features with branches, tags and merge in the wiki integrations that we have.
GreenPepper promotes a very inclusive approach and we thought that customers and users involved in development team would find it too technical and would be confused by branching and merging features.
In GreenPepper the users simply modifies and save. He doesn’t even need to understand versioning. It cannot be simpler.
Some developers ask me: But how do I keep track (tag) of the specifications when we do a release. I cover this in details in the Put your specifications in the freezer blog post.
It is usually not long after adopting the Executable Specification practice (aka Example Driven Development, Acceptance Test Driven Development – ATDD, Story Test Driven Development – STDD) that good software teams want to integrate GreenPepper in their build process. This is an area where we think GreenPepper shines.
GreenPepper allows for a smooth process of adding / modifiying specifications -> implementing in TDD style -> committing code and specification –> automated continuous build.
Let me walk you through what happens.
At the beginning (and during) of an iteration or sprint some specification pages are modified or added. GreenPepper keeps track of the implemented vs working copy.
The various build tool integration we have (Maven, MSBuild, Nant …) will continue to use the implemented version therefore your build is not broken and you do not need to move the modified or added pages in a temporary area. Great!
At some point a developer will assign himself to the implementation. In his favorite IDE (Eclipse or Visual Studio) he can easily locate the modified specification page and switch to the working copy
Then he executes the page and should see the page not passing
Then he goes and develop the code TDD style with his favorite unit testing tool integrated in his IDE (JUnit, TestNG, Visual Studio, Nunit, etc.) He can frequently re-execute the page and see it slowly turn from red to green!
Once it is all green, he commits his code in the source control and from the IDE he sets the specification page as implemented.
The next build will use the committed code and page and life will be Green!
En découvrant les nouvelles fonctionnalités de GreenPepper 2.6 j’ai eu envie de les partager au plus vite ! GreenPepper autorise maintenant une syntaxe très flexible pour exprimer des scénarios (ou cas d’utilisation) dans un formalisme qui peut être défini en collaboration entre les experts métiers et développeurs. Le mot–clef associé à cette syntaxe est « scenario ». Je vais vous montrer dans ce billet comment utiliser GreenPepper pour exprimer des exigences sous la forme « Given, When, Then », formalisme recommandé par le courant « Behaviour Driven Developpement ».
Un cas concret à spécifier
Prenons un cas concret d’exigences fonctionnelles. Spécifions le comportement d’un agent virtuel d’assistance, dont le rôle est de répondre à des demandes d’aide en trouvant des interlocuteurs pouvant satisfaire les demandes d’aide.
Les principales « user stories » seraient les suivantes :
- En tant qu’utilisateur ayant besoin d’aide, afin de trouver une personne qui pourrait m’aider, j’interpelle l’agent virtuel afin de lui décrire mon problème.
- En tant qu’utilisateur ayant besoin d’aide, afin de trouver une personne qui pourrait m’aider, je souhaite contacter une personne disponible et disposée à m’aider.
- En tant qu’utilisateur pouvant apporter mon aide, je souhaite être contacté par l’agent virtuel afin de proposer mon aide.
Reformulons maintenant sous la forme d’exemples certains cas d’utilisation :
| Etant donné que Marc n’a jamais contacté l’agent virtuel |
| Quand Marc dit à l’agent virtuel « Hello », |
| Alors l’agent virtuel lui répond « Que puis-je faire pour t’aider ? » |
| Quand Marc dit à l’agent virtuel « Je n’arrive pas à installer Credanse+ sur MacOS » |
| Alors l’agent virtuel lui répond « J’ai bien pris note de ta demande d’aide et te contacte dès que possible » |
| Etant donné que Marc a déjà formulé la demande d’aide « Je n’arrive pas à installer Credanse+ sur MacOS » |
| Etant donné que Steve est disponible |
| Etant donné que Marc n’est pas disponible |
| Quand l’agent virtuel contacte Steve pour lui dire « Marc a besoin d’aide, il m’a dit : Je n’arrive pas à installer Credanse+ sur MacOS . Acceptes-tu de l’aider ?» |
| Quand Steve dit à l’agent virtuel « Oui » |
| Alors l’agent virtuel lui répond « Merci, je vais en faire part à Marc et il te contactera dès que possible » |
Spécifier dans GreenPepper
Voyons comment écrire le premier scenario avec GreenPepper :
Dans notre espace collaboratif d’édition de spécifications (Confluence ou XWiki), nous saisissons le tableau suivant :
Mettons un peu de couleur pour faire mettre en relief ce qui relève de la syntaxe et ce qui est en rapport avec les données du scénario.
Coder la classe de test
Maintenant, nous devons écrire la classe de test (ou fixture). Une première implémentation naïve de cette classe pour faire passer le test est :
public class AgentVirtuel
{
private string lastwords = “”;
private string lastuser = “”;
public AgentVirtuel()
{
}
[Given("Quand (\\w+) dit à l'agent virtuel ([\\w|\\s|\\'|\\-|\\?]*)”)]
public void WhenUserTellsTheAgent(string userName, string words)
{
lastwords = words;
lastuser = userName;
}
[Then("Alors l'agent virtuel répond ([\\w|\\s|\\'|\\-|\\?]*)”)]
public void ThenTheAgentAnswers(Expectation answer)
{
if (lastwords==“Hello”)
{
answer.Actual = “Que puis-je faire pour t’aider?”;
}
else
{
answer.Actual = “J’ai bien pris note de ta demande d’aide et te contacte dès que possible”;
}
}
}
Dans cet exemple C# (il est possible d’écrire la même fixture en Java avec GreenPepper), nous voyons des attributs en charge de gérer la correspondance entre chaque « phrase » du scénario et une méthode de la classe de test.
Le mot-clef « Given » permet de définir ou d’initialiser un comportement qui ne sera pas testé. Par contre, le mot-clef « Then » permet de déclarer des attentes et de les tester. Dans cet exemple, nous testons la réponse de l’agent virtuel.
Exécuter la spécification
Exécutons notre spécification avec GreenPepper et observons le résultat :
Après exécution, une confirmation visuelle affiche automatiquement en vert les parties de texte qui ont été vérifiées positivement par GreenPepper. En cas de confirmation négative, la couleur rouge sera utilisée.
En conclusion…
Nous voyons à travers cet exemple, que l’utilisation d’expressions régulières associées à des méthodes de la classe de test, permet une grande souplesse ! Aux équipes de jouer et de trouver une syntaxe qui facilitera une compréhension partagée entre toutes les parties prenantes du projet ! Cette compréhension partagée sera de plus testable en continue!
This new release includes a new Scenario interpreter that have a BDD style, XWiki integration (use XWiki to write your executable specifications), a plugin for Grails, a better compatibility with Confluence 3.0 and up, many improvements to the PHP extensions (Thanks to folks at Astria) and bug fixes.
See the release notes for more details…
As mentioned on Sonar’s blog, we are at Agile 2009 and we have a booth to demonstrate our products including GreenPepper and the newly released plugin for Sonar. We can also show you Sonar itself and the results on GreenPepper itself. The results are pretty good, not too much technical debt
You are also invited to attend the conference given by Erik Lebel and Isabelle Therrien on Scrum: “From anarchy to substantial development: Scrum in less than ideal conditions“. Read the full article. It will be held next Thursday (August, 27th) from 9:00 to 9:45 in room Plaza A (East Tower).
Follow our coverage of the conference here.
|
|
