Archive for the ‘Test Driven Development’ Category
The best coding dojo ever
I've got goosebumps on my arms most of the day. And it doesn't happen very often. This is the most emotional coding dojo I've ever facilitated. It's been in Gran Canaria, at the Universidad de Las Palmas de Gran Canaria (EII ULPGC).
The last day in college for some students, where many of them were thinking of their uncertain near future. Asking for recommendations and expressing many doubts.
More than 50 people coding together for more than 8 hours, in an incredible atmosphere.
How did we get here?
There is only one book on TDD in Spanish so far. Published by my friends and me back in 2010, under the creative commons license. Creative commons is like a virus for this. One year ago a real master, Jose Juan Hernandez (@jjhernandez) decided the book was nice to teach his students how to write clean code. We didn't know each other. In fact I didn't know the book was being used at the University. Jose Juan has been coding since 1985 and I do believe he is a software craftsman, now that I've seen him coding and teaching.
A couple of months ago he contacted me see if I could give a talk to his students, about TDD in the real world™ and the encounter was excellent. The coding dojo proposal came along right after that.
Why has it been so good?
Guillermo and I
Several factors in here. Jose Juan has been teaching TDD, Refactoring, Patterns and Clean Code to his students the whole year. No only the practices but the values. This is the reason we believe he is a master, because his students have embraced and internalized his values and principles.
- So about 30% of the students were familiar with the techniques, and we asked them to pair up with those not exposed to automated tests and example driven design before. And they explained everything to others with passion.
- In a regular coding dojo the facilitator does not necessarily teach. Her goal is facilitating. In this case though, we've been teaching people, so it's been half of a training session. With direct feedback on their work, based on our experience.
- We were 3 guys facilitating: Guillermo Pascual (@pasku1), Jose Juan and me. And the sinergy it's been huge.
- Everyone was absolutely willing to learn and share. Passionate people, warm and friendly.
- It's been a total win-win event. We (facilitators) have felt very useful and appreciated, it's been fulfilling. Some people have discovered a new way of understanding their careers, and what "caring about code" means.
- The retrospectives following every iteration were very participative, people were able to discuss among them.
Jose Juan
What's next?
- This is a milestone in the Canary Islands software development community, I can feel it. Something is changing...
- Let's keep on practising together. The AgileCanarias community is growing and it's a good starting point o meet new people and learn new stuff. The Tenerife group is kind of mature and stable now, let's do the same in Gran Canaria. And let's join the two groups for dojos and local conferences.
- We have the Agile Open Space this year in Tenerife. Join us, it's a great opportunity to discover more.
- Now you know there are different ways of writing software. Keep on learning, it's a never ending path.
- When is the next coding dojo, who will organize and facilitate it?
I want to facilitate a dojo, what should I know?
- Manage people's expectations. In general a coding dojo is not a training session. Be honest with participants and help beginners as much as you can. Otherwise they'll be scared, run away and take a wrong idea about what it is.
- A dojo is a space for innovation, try different things all the time, you don't have to follow the manual on the go. Just use your imagination and empathy.
- Ask someone experienced to facilitate it before doing it yourself, if possible.
- There is an interesting new book on this by Emily Bache: https://leanpub.com/codingdojohandbook (haven't read it yet), foreword by Uncle Bob Martin.
- Check out this video by Emily Bache: http://www.youtube.com/watch?v=yao5XLJqogQ
Acknowledgments
- Jose Juan and Guillermo Pascual.
- All the participants, of course. Without them, there is nothing to do.
- Jorge Castellano for his pictures and video. Pictures will be uploaded soon here. Jorge already uploaded some pictures to twitter. Just search for the hashtag #dojoULPGC
- Fran Santanta for his support and organization. Fran brought journalists from local newspapers and TV, apart from the food and everything else.
- Mario Hernandez Tejera for his company, hospitality and sharing his interesting/wise thoughts.
- All the colleagues who work with Jose Juan for his support and energy.
- JM Beas, Xavi Gost and other folks from Agile Spain, as they introduced me to coding dojos.
This is the related thread in the AgileCanarias mailing list.
What would you expect the code to do?
Writing quality code is about satisfying the expectations of the reader. And the reader might be yourself a couple of months later.
Let me tell you a mistake a made recently. I was test-driving a few classes and one collaborator was a stack. But I only needed the stack to give me the last two items pushed on top of it. So I ended up with a function like this:
function pop(numberOfItems){ // ... some code dealing with border cases... // and the happy path: return [items[len -1], items[len -2]]; }
And everything went well. The stack was good enough for the object using it.
After a few months I needed to use the stack again but I forgot about its internals. I was writing some tests for a new class also depending on a stack. As the stack was already tested, I stubbed out the "pop" method in the new test pretending it could give me the last 3 items on the stack. The unit tests passed and my new class was working fine with the stack. However, it didn't work into production. Lesson:
Although TDD encourages you write only the smallest amount of code necessary to make the test pass, you should implement all the behavior a method is expected to have when someone reads its signature.
In one way or another I was coupling the stack to the class using it. But APIs should always tell the truth. Classes and methods should do what their name say without the need to know how other artifacts consume them.
Careful with JavaScript object literals
JavaScript object literals are very handy, they are just key-value pairs. Very convenient to implement dictionaries and also a very simple implementation of the Singleton pattern:
var message = {sender: 'bob', body: 'hello'};
Duck typing is a technique I use very often as I test-drive my JavaScript code and object literals make it very easy. But overusing them lead to several problems:
- Feature envy code smell
- Anemic models
- Refactoring difficulties
I am no longer using object literals in my tests because when I need to add methods to those objects, I need to change too many tests. Also, exposing all those fields lead to feature envy rapidly, producing semantic coupling sooner or later. Although tests are written fast with object literals, I prefer to encapsulate the fields into business objects.
function Message(sender, body){
this.sender = sender;
this.body = body;
}
var message = new Message();
Push the “how” down: Cukeup! 2013
It's been my first time attending to an event at Skills Matter and it's been awesome 
Cukeup! is the annual conference about BDD and Cucumber. This was the third edition. Let me share with you the ideas I listened yesterday. The ideas and sentences written in here are not necessarily what speakers said, this is just my understanding of them. You can now view the talks online from the SkillsMatter site.
- Keynote by Aslak Hellesøy - father of Cucumber and coauthor of the excellent Cucumber book (which I recommend) and Cucumber Recipes (brand new):
Aslak told us how the development of Cucumber is going and the new design ideas they are working on, together with a review of the many flavors Cucumber's got. I missed a reference to SpecFlow in the slides though, as it is one of the tools I use and I think Gaspar Nagy is doing a great job (and he came to the conference by the way, which was nice). The thing I liked the most from this keynote was that he announced their new book recently published, Cucumber Recipes, which is now on top of my wishlist. And also the honest way he talked about the architecture redesign Cucumber needs and how are they approaching it. This is a good example of why architecture and design are so important.
- One-line step definitions with Matt Wynne - coauthor of the two books mentioned before:
You can see the talk online here (and so the others too). Having read his first book, the new ideas I got from this insightful talk was that the popular test pyramid can be "rotated". Matt and Seb Rose came across this idea together. Basically, you can use Cucumber to describe features without the need to access the application end to end, just exercising low level classes and methods from the step definitions. In those cases Seb decorates the features with tags indicating the level of abstraction they belong in (@without_ui for example). If you haven't read Matt's book, this talk is a good summary of some parts, it features some of the most important values and principles. Remarkable ideas:
Push the "how" down because it changes often and because it will not bring people into BDD as the features written in the imperative way are hard to understand and boring, cluttered with irrelevant information. Sometimes imperative style is the result of ignorance but it can also spot lack of trust in the team. And... don't nest steps (call another step from the step definition).
- Working in the Cucumber World with Andrew Premdas:
Andrew's advise is to benefit from both, natural and programming languages when we write features and their step definitions. In order to do that, the "World" (fixtures used within step definitions) must be expressive, self-descriptive. Although he discouraged us from using global variables, there are some exceptions, something useful when referring to oneself in the fixtures is to use the variable "I" (@I in Ruby). Enrique Comba also suggested using @narrator (@ comes from Ruby) as the variable used to refer to the person telling the story. Because "narrator" might be clearer than "I" when there are many steps. Andrew said it was his first talk and he did very well in my opinion because clearly his primary concern was to communicate, so the message came out effectively.
- Don't you trust me? with Seb Rose:
Trust is easier to loose than to win. When developers tell testers that everything is fine but then it breaks, they are loosing points. Same when developers don't allow testers to navigate through the code base. Testers can work more effectively if they know a bit of programming and are able to check out the source code for inspection. When team members trust each other they clean up the road for others. Documenting high level architecture and components also helps.
Then he explained an experiment he is trying out: end to end tests are good to win trust so he starts by exercising the application like that from the features. But after that, he considers whether end to end is really the right way to go, because maybe exercising low level methods rather than several layers is cheaper, as long as there are already other end to end tests covering the path. Again, the rotated pyramid.
- The Impersonator Pattern with Enrique Comba:
Enrique got many of us thinking how to leverage the pattern right after his talk. He explained it on his blog time ago. A very nice secondary effect of this pattern, is that one can rapidly review the implementation of the impersonators and get a summary of what every persona in the project can do and what can't do. Useful documentation to have, specially when you have hundreds of features and thousands of steps. It was definitely a great talk, source of inspiration. His craftsman spirit lead him to this pattern as the consequence of following the "maximize code clarity" principle.
- Hands-on Cucumber.js with Julien Biezemans and Matt Wynne:
Julien, the creator or Cucumber's JavaScript flavor was pairing up with Matt to test-drive a little game live, writing the code directly in the browser with particular web environment set up by him. I am already using Cucumber.js so nothing new about that but I didn't know about uitest.js which they were using during the session. I am actually doing something similar on my own with Jasmine to run the app within an iframe so is good to know that more people are doing that. Some other times I just run cucumber.js from the command line using zombie.js.
- Cross-platform BDD for Mobile with Karl Krukow:
Karl showed Calabash, a very powerful framework for mobile testing. Really impressive to me. It fits perfectly with hexagonal architecture and helps to avoid duplication in the tests while testing native apps on different mobiles platforms. It's really worth having a look at Calabash. I'll definitely will do. Of course the integration with Cucumber is excellent.
- Testing web apps with Cucumber.js with Paul Jensen:
Good speaker, nice technical stack and good ideas from the talk. He showed code from his successful app Dashku and its tests. I must say that the way I write JavaScript apps is different specially because I test-drive them whereas he showed a prototype developed without tests, having them added afterwards. But still, some good points in the talk.
Now I'll watch all the sessions that I couldn't attend to (haven't found the way to split myself in two).
See you next year hopefully!
Unit testing JavaScript with Promises and Jasmine
Promises are a nice solution to write readable asynchronous code in JavaScript. If you understand Spanish, I highly recommend this great talk on Promises by Enrique Amodeo.
But, is the code with promises easy to unit test? It's not very difficult, you have to take into account the calls are asynchronous even if the production code executes instantly.
Here is some code I've written using when.js library:
function TicketSalesService(){ var self = this; // ... some other code over here... this.buyTickets = function(quantity) { purchaseOrder.quantity = quantity; // THIS IS THE CODE WITH PROMISES: this.server.isUserRegistered(user) .then(tryToBuyTickets) .then(informSubscribersAboutPurchaseResult) .otherwise(function (err) { helpers.registerPromiseError(self, err); }); }; var tryToBuyTickets = function (response) { if (!response.registered){ self.onRegistrationRequired(); // trigger event throw helpers.endOfPromiseChain; // stop the chain } return self.server.buyTickets(purchaseOrder); }; var informSubscribersAboutPurchaseResult = function (response) { if (response.success) self.onPurchaseSuccess(); else self.onPurchaseFailure(response.message); }; this.onRegistrationRequired = function() {/* event */}; this.onPurchaseSuccess = function() {/* event */}; this.onPurchaseFailure = function() {/* event */}; // ... some other code over here.... };
In this code there is a helper namespace providing a function and a constant:
helpers.endOfPromiseChain; // this is just a constant, a string. // And this is a function to ease testing: helpers.registerPromiseError = function (target, err) { if (err != helpers.endOfPromiseChain){ target.errorInPromise = err.toString(); } };
The "server" dependency in the TicketSalesService is just a jQuery ajax wrapper. There is a rule in TDD that says, "do not mock artifacts you don't own". What I do is wrap up jQuery.ajax so that I can easily stub out the server response and also change jQuery for other library if I needed to.
Service.prototype.isUserRegistered = function (user) { var deferred = when.defer(); // wrapping jQuery aja: this.requestData("theUrl/goes/over/here", { data: user }, function(data) { // jQuery.ajax success invokes this deferred.resolve(data); }); // TODO. call deferred.reject(); on error return deferred.promise; };
What about the tests? I am using Jasmine as the testing framework. I test-drove the code above and these are the resulting tests:
it("triggers event when server responds that the user is not registered", function () { stubServerResponse(salesService.server, { registered: false }); var promiseSpy = spyReturningPromise(salesService, "onRegistrationRequired"); salesService.buyTickets(5); assertAsyncExpects(promiseSpy, salesService); }); it("tries to buy when server responds that the user is registered", function () { stubServerResponse(salesService.server, { registered: true }); var promiseSpy = spyReturningPromise(salesService.server, "buyTickets"); salesService.buyTickets(5); assertAsyncExpects(promiseSpy, salesService); }); it("triggers event when tickets are purchased", function () { stubServerResponse(salesService.server, {success: true, registered: true}); var promiseSpy = spyReturningPromise(salesService, "onPurchaseSuccess"); salesService.buyTickets(5); assertAsyncExpects(promiseSpy, salesService); }); it("triggers event when prescriptions could not be purchased", function () { stubServerResponse(salesService.server, {success: false, registered: true, message: 'fatal'}); var promiseSpy = spyReturningPromise(salesService, "onPurchaseFailure"); salesService.buyTickets(5); assertAsyncExpects(promiseSpy, salesService); });
My code is using DOM Level 0 event handling. You can read more about event driven design in this former post.
The tests are very clean if you are familiar with Jasmine spies.
The method "stubServerResponse" replaces the function "requestData" in my "server" object to simulate data coming from the server.
The other helpers are here:
var assertAsyncExpects = function(promiseSpy, target, additionalExpectation) { waitsFor(function () { return promiseSpy.called || target.errorInPromise; }, 50 ); runs(function () { // this tells me if there was any unhandled exception: expect(target.errorInPromise).not.toBeDefined(); // this asks the spy if everything was as expected: expect(promiseSpy.target[promiseSpy.methodName] ).toHaveBeenCalled(); // optional expectations: if (additionalExpectation) additionalExpectation(); }); }; var spyReturningPromise = function(target, methodName) { var spyObj = {called: false, target: target, methodName: methodName}; spyOn(target, methodName).andCallFake(function () { spyObj.called = true; return when.defer().promise; }); return spyObj; }
These two are basically wrappers around Jasmine to remove noise from my tests. The funcionts "waitsFor", "runs" and "spyOn", belong to Jasmine. The first two deal with asynchronous execution whereas the third one creates a test double, a spy object.
What are the tricky parts?
When there is an exception inside the "then" or "otherwise" functions, it is captured by the promise and the test doesn't know anything about it. So when the test fails, it might not be for an obvious reason, and I want my unit tests to tell me where the problem is very fast. So I create a property in the object containing the "then" methods, called "errorInPromise" that I can check later in my tests. I add the "otherwise" handler at the end of the "then" blocks to ensure any exception thrown within them is captured and can be read in the tests.
What do you do to unit test your "promising code"?
Charla sobre agilidad, testing y TDD en la ULPG
Gracias a Jose Juan Hernández, profesor de ingeniería del software de la Escuela de Informática de la Universidad de Las Palmas de Gran Canaria, ayer 12 de marzo pudimos grabar la primera video conferencia con su clase. Hablamos de métodos ágiles, de testing y de TDD.
Tuve algunos problemas técnicos y no se si la parte de preguntas se grabó también. Pero seguramente no será la ultima colaboración porque ha sido muy enriquecedora para mí.
Muchas gracias a Jose Juan por hacerlo posible y a sus alumnos por el gran interes mostrado durante la sesión.
Esta es la primera noticia que tengo de que nuestro libro de TDD se esté usando como material docente en la Universidad. Es una gran noticia y me anima a publicar una nueva version mejorada.
Event oriented programming with JavaScript
Event oriented programming promotes low coupling but not necessarily high cohesion. Always consider the Single Responsibility Principle while designing collaboration through events. I see three primary ways of collaboration:
One to One
A single object communicates with other (a collaborator). This can be done with dependency injection the same way we do it in Java or any other language (and you don't need Spring for that!). JavaScript provides another mechanism for one2one communication, the DOM Level 0 traditional way of event handling. A very useful and powerful way of adding hooks/ports to plug new behavior in, still promoting low coupling. If you need to change the collaboration in the future, from one2one towards one2many, it can be done easily. In some cases I see this as a more decoupled way of dependency injection.
function Car(){ this.go = function(){ /* some calculation over here */ this.onLowFuel(); }; this.onLowFuel = function(){/* event */} } function RacingTeam(){ function getReadyToFuel = function(){/* whatever */}; this.addCarToRace = function(car){ car.onLowFuel = function(){ console.log('low fuel!', this); getReadyToFuel(); } }; } var car = new Car(); var team = new RacingTeam(); team.addCarToRace(car);
As you might realize I know nothing about car races but I hope you understand the code. When implementing traditional dependency injection, the car knows it depends on a team, but it doesn't know the particular implementation of the team. With the DOM level-0 traditional way, the car doesn't even know it will be used in a team. All it knows is that it has to inform someone else about its fuel level when it gets low. However, the team's got to know about the car. Still the team should not know about the particular implementation of the car.
To test-drive this behavior, you probably need two steps. First one, make sure the car triggers the event and second, make sure the team handles the event. I wrote the two tests in a previous post. DOM level-0 traditional is the main mechanism I use for one to one collaboration, it's got however some pitfalls worth considering.
Pitfalls
- You might not know some object is already handling the event: the handling mechanism is simple, we are just replacing the original function in the object triggering the event. If we try handle the same event twice, there will be only one handler, the last one. I always use the "on" prefix for those methods that trigger events as a convention to know it is an event with a single handler.
- You might make mistakes with the "this" keyword: in the code above, what do you think "this" is when we invoke console.log? It's the car object, not the team. It's a problem with a very easy solution though. I usually have a reference to the handler doing "var self = this;". Some people prefer the "bind" method to do the same.
One to Many
For one to many collaboration there is the Observer pattern. jQuery implements the observer pattern to expose events such as "click":
$('#closeButton').click(function(){ /* the event handler 1 */ console.log('handler1'); }); $('#closeButton').click(function(){ /* the event handler 2 */ console.log('handler2); });
When the button is clicked, both handlers are executed. When I implement the observer pattern in my objects, I prefer to make it explictly:
objectTriggeringTheEvents.addSubscriber('eventName', handler1); objectTriggeringTheEvents.addSubscriber('eventName', handler2);
The "addSubscriber" makes clear to me, that I can have several subscribers. This is specially important to distinguish from one2one collaboration.
As an exercise I leave out to you the implementation of the observer pattern with TDD.
I use one2many collaboration when I really need the object to be observed by several objects, which happens to me, less often than one2one collaboration.
Many to Many
Different objects might trigger the same event and there might be a bunch of other objects subscribing that event. This is the case of a many2many collaboration. Or, I might not be interested in the source of the event, I might just want to handle it. This usually happens at the infrastructure level. For example I use it to know when the window is being closed. I don't care who is responsible for realizing the window is being closed but I do want to know it in several parts of my application to shutdown properly. So I create an object which subscribes to "window.onbeforeunload" to be aware of window closing and in turn, emits the event through a "bus" where subscribers are listening.
This is the less coupled way of interaction between objects, but it comes with counterparts: code gets harder to follow. This is the publish/subscribe pattern. My advise is to use this pattern only when strictly necessary and not as a the default mechanism for event oriented programming.
There are several open source libraries implementing this pattern. As an exercise, try to develop it from scratch, test-first. This is the code I ended up with while implementing my own pub/sub:
EventBus = function(){ var subscribersInfo = []; this.addSubscriber = function(callback){ var eventNames = [].slice.call(arguments).slice(1); subscribersInfo.push({ subscriber: callback, eventNames: eventNames}); }; this.emit = function(eventName, eventArgs){ for(var i = 0, len = subscribersInfo.length; i < len; i++){ var info = subscribersInfo[i]; for (var j = 0, lenj = info.eventNames.length; j < lenj; j++){ if (info.eventNames[j] == eventName) info.subscriber(eventName, eventArgs); } }; } };
BDD applied to JavaScript RIAs
The big picture (click to enlarge). Drawn with LucidChart.com
Is there any difference in the implementation of Behavior Driven Development in the case of a Rich Client Application (or Rich Internet Application) ?
BDD's primary goal is communication. In that regard, there are no differences. However I see the differences in the outside-in implementation techniques.
There is no need to test the application through the GUI to make sure the specifications (customer acceptance criteria) are met.
With JavaScript we can easily test anything in the GUI with the help of the Passive View Pattern and some fine-grained integration tests against the DOM. This means that I can ensure the GUI connects with the application using unit tests + fine-grained integration tests. I can cover all the paths with automated tests, most of them unit test.
In a traditional website I can't "mock" a panel (or any other view) to check that some text has been added to it as a result of a "click" event triggered by a button. In fact, we can't use truly event oriented programming. Because the UI is just a picture, rather than a set of objects with methods, behavior. With JavaScript this is a big advantage because we can use test doubles for those views in the unit tests, and then write contract tests to make sure those views manage the DOM properly. As a result, what in traditional web development have to be integration tests, now are unit tests.
We are back to those days where libraries to handle GUIs were so powerful and nice for both, developers and users. This time with 10+ years experience in agile testing and all kind of testing tools.
Thanks to this fact, we can design a Ports and Adapters Architecture for our application so that the GUI is just another port, at the same level than the acceptance tests. I can express the scenarios using plain JavaScript (or CoffeeScript) accessing the application through the "tests adapter", ignoring any GUI detail.
If I use Cucumber (I am using SpecFlow right now), my step definitions do not hit the UI. They just load the page and access the Business API (test API).
[Given(@"^I start a new task$")] public void GivenIStartANewTask(int minutes) { var browser = ScenarioContext.Current[browserKey] as IWebDriver; var navigation = browser.Navigate(); navigation.GoToUrl(appUrl); var jsExecutor = browser as IJavaScriptExecutor; // invoking my JavaScript Business API here var invoked = (string)js.ExecuteScript( "return app.startNewTask();"); // making sure the Business API got the call invoked.Should().Be("newTaskCreated"); }
The "Should" comes from FluentAssertions. The browser is Webdriver (Selenium).
If I don't user Cucumber, another option is to directly write the scenario with CoffeeScript.
describe "LiveTeamApp: the team productivity application", -> beforeEach -> loadApp(appAddress, initTests) describe "the tasks management system", -> it "counts the time consumed by every task", -> app.startNewTask() waits two.seconds app.finishCurrentTask() app.lastFinishedTask.elapsedSeconds.should.equal(2)
This is Jasmine plus Chai's syntactic sugar (should).
This scenario is actual code from my application LiveTeamApp.com, which has been developed entirely following this process (please check it out with your team, I believe you will like it 
Notice how I am writing a programmatic interface (the test adapter) to talk to the application with the language of the domain.
For asynchronous cases, I am writing a small fluent API called Flas, which uses Gherkin to encapsulate blocks containing jQuery ajax requests. The Given-When-Then blocks scope asynchronous calls so that every block is executed once the calls have finished.
For more complex scenarios where I need several instances of the application at the same time (to design and test how users interact with each other), I am using CasperJS. This the case of LiveTeamApp's chat service, where users can chat with each other and also chat with the whole team. The acceptance criteria has been written with CasperJs to open several browsers and use the programmatic API from all of them to interact. Again, no need to hit the GUI in those acceptance tests.
My friend Ivan Stepaniuk and I presented this work and ideas first in Agile Testing Days 2012. Since them I am improving my technique, to write better and better acceptance tests.
The workshop
If you want to learn more and practice the technique, I encourage you to attend to my workshop. In the workshop you practice the whole BDD cycle, from the specifications workshop to the views implementation. See more information about the workshop in this post.
The book
I am starting to write a book on this. If you want to help me out with it please let me know. I expect it to be published in late 2013 or 2014. There is a great book on TDD with JavaScript written by Christian Johansen. It covers thoroughly all you need to get started with JavaScript and TDD as well as advanced topics. I'll try to write my book as a complement to Christian's. My TDD style is a bit different from Christian's but my motivation to write the book is not because of that, but to show readers the whole BDD cycle in a rich client application.
I won't repeat the great lessons you can read in The Cucumber Book which is a must-read. Even if you are not using Cucumber, Matt's and Aslak's book is fantastic to learn BDD.
The other books I would expect my readers to read before, are the ones by Gojko Adzic on Briding the Communication Gap and Specification by Example
Workshop: BDD for RIAs with JavaScript
This year I will tour Europe with my new workshop: Behavior Driven Development for Rich Internet Applications using JavaScript.
Who is this workshop for?
JavaScript developers. This is a workshop for those developers who already have some experience with TDD and JavaScript. I will not explain what an automated test is, I expect attendees to be familiar with the notion of test-first development. However, you don't have to be a TDD expert to join the workshop. Some experience with test doubles (mock, stubs...) will help, although we will review them in their JavaScript version.
Attendees must be familiar with dynamic languages and must have a good JavaScript knowledge. Although a deep knowledge of the JavaScript language is not required, it is important to be used to the language, at least practicing code katas. I have prepared these exercises to make sure we all can expect a certain level of JavaScript knowledge. I help with any doubts on those exercises.
Important: Aim of this workshop is to teach developers how to develop rich client applications, not a website with some JavaScript on it. Mobile apps based on JavaScript fall into this category.
Workshop contents
BDD is a full stack methodology. In this other post you can read how I am implementing BDD for RIAs. We will develop several user stories from the ground up, starting from the specification workshop and ending with working software. This is the table of contents:
- Communication: some advise for effective communication and productivity.
- Specification workshop: requirements and business value.
- Agile JavaScript infrastructure: everything we need to get started.
- Cucumber and its many flavors: examples with cucumber.js and SpecFlow
- Event oriented programming.
- Testing techniques with JavaScript and test doubles.
- Most common design patterns: ports and adapters, passive view, observer, factory, singleton.
- Architecture: those other things that don't emerge from the design but have to be thought upfront.
Everything is practical. Attendees work in pairs, rotating every now and then to be able to pair up with at least four people. Pair programming is explained in the workshop and I am facilitating and helping pairs all the time. We stop after each exercise to add some theoretical notes and recaps.
Why JavaScript?
I used to think that JavaScript was something terrible, even worse than PHP But it is no longer like that (PHP has also improved!). The JavaScript platform is so powerful these days. It's quite mature and evolving very fast. Mainly because browsers are improving a lot. Even our good friend IE, is negotiation a truce with developers in its latest versions.
Desktop applications were so powerful back in the 90's regarding the user experience and the programming techniques. The web as it came in the 2000 decade, was a step back in terms of tooling and user experience but it was a huge advantage in terms of deployment. Now we can leverage everything that has been effective in the past 20 years: rich user experience, powerful programming techniques and tools, agile testing, and high market potential (web and mobile). JavaScript platform means to me the JavaScript language and also CoffeeScript and any other language which compiles into JavaScript.
Is BDD different for JavaScript?
Not really from the high level. However, rich client applications are now easier to test than ever. What in traditional web development are integration tests, now can be turned into unit tests, making maintenance much more efficient. The actual instances of the objects in our application are directly accessible in our tests, there is not need to hit the application through the GUI to run end to end tests.
The amount of glue code or automation code can be reduced or even removed in some cases. It is worth understanding the differences to take advantage of rich client side development.
Should you attend this workshop?
This is a career investment. If you don't expect to practice any learned lesson from the workshop, better you save your money. On the other hand, if you come to the workshop willing to learn, ask and practice, this workshop will save you a lot of time, effort and mistakes. Every time I invest my money in training I try to calculate the ROI somehow and have a clear reason as to why am I doing that investment.
In this workshop you will understand the best practices that took me years (and pain) to learn. You will be ready to apply them in your upcoming projects. It is impossible for you to master all the techniques after a single day but you will get a solid foundation to start from and knowledge to avoid critical mistakes.
Is there any sample application developed this way?
Yes there is! Check it out for free at LiveTeamApp.com, my latest and coolest application for team productivity.
The bonus
When you enroll on the workshop you also get homework and homework help. You can send me any questions you have, anytime. You also get access to a mailing list where you can get new exercises, news, and more. Because I don't just want attendees for the workshop, I want people to learn so I'll help you keep on learning.
You can buy your ticket now
The next edition will be in Postdam, Germany. It will be part of AgileDevPractices (March 4, 2013). Following editions will be published here (look in the right-hand sidebar). If you would like to host the workshop in your city, please contact me.
Pricing: Early Bird 750€, Regular 850€. Buy Now
Tell me more
Do you want to know where and when is the next workshop edition? Join the mailing list. You will not receive any spam, I promise
Agile Testing Days 2012 was awesome
Look at me. I am so exhausted and happy at home... because I come from Agile Testing Days 2012! (Postdam, Germany).
One of the best conferences in the world for agile testers, managers and developers. It's been my first time in this event. First of all, I want to say thank you to José Díaz, Madeleine Griep, Uwe Gelfert and the whole #AgileTD team brought by Diaz & Hilterscheid. Everything has been excellent. Everything on time, precisely calculated and performed... as if they were German!
My friend Iván Stepaniuk and I landed in Berlin on monday afternoon. It was easy to get to Postdam by train. The strong chocolat smell in Postdam's train station is the best welcome message for two hungry geeks :-)
Curiosities
At 6.30pm a bus gave us a lift from the hotel to the speaker's dinner in a nice restaurant where food was excellent and the wine was Spanish So the networking started from minute one. I didn't know any of the guys in the table and had a great time talking to them. Something I really appreciate is that we were back in the hotel at... 11pm? or maybe sooner, so there was plenty of time to sleep and get ready for the next day.
Then conference started on Tuesday at 9am but before that, Lisa Crispin facilitated an open space called "the lean coffee" starting at 7.30am for those early birds who wanted to ask questions or share experiences. I enjoyed the time there. There was "lean coffee" also on the next two days but I was just destroyed and needed to rest.
Everyday was absolutely busy with one activity after the other and plenty of food in the hall all the time. Very handy because you don't waste time going for food, it is always available and you eat standing on your feet having the chance to talk to people. Perfect for networking and for those like me who forget what time is the lunch supposed to be.
On Wednesday night buses took everybody to the "Most Influential Agile Testing Professional Person award" dinner. A special place where again the food was spectacular and there was an awesome magician, a beautiful acrobat (this was the music, a Metallica cover), and live music. And.. the award went to Lisa Crispin! Congratulations!
One thing that grab my attention is that the majority of the speakers are self-employed, independent professionals (including myself). Some of them have been working for important companies but end up working for themselves. What do you think this means?
What I have learned
As a developer I have learned that good testers are methodical and share the same passion for continuous improvement. Developers should know something about testing and testers should know something about development. But a great developer is never going to be a great tester, and a great tester is never going to be a great developer. Both roles are necessary in teams. And the job of testers should not be placed at the end of the iteration but at the beginning. Quality products can only be developed when quality has been in place since the beginning. It is not that quality can be added at the end.
Design for quality the same way you write code for testability,... quality-first development!
I have learned that good testers love their jobs.
At this point it is well-known that the majority of the defects introduced in software have to do with people and mistakes in the communication.
Apart from this general thoughts I learned something in every talk, every keynote and every chat during coffee breaks or dinners. I tweeted some of the most remarkable sentences I listened using the hashtag #agileTD.
Talking to more experienced consultants also helped me confirm that some ideas I have work for them. And some points of view make sense to others too.
Something new I will try to apply
On my current project, the product owner come up with feature requests for the team to work on, and once they go live, it turns out that they are not really used sometimes. But we don't get the chance to discuss why should they be implemented. Some discussions end up with the product owner saying, "I know the business and this should be done".
I'll try to introduce the idea of testing business assumptions. Design in a way that allows us to determine whether changes are really impacting the business.
I will ask ... "How will we know if this change (feature request, bugfix or behavior change) as a negative or positive impact on our users?". It is about creating business measurable software for metrics to be easy to find.
I believe these ideas come from the lean startup movement. The were expressed by Gojko Adzic based on his experiences.
Mind maps might help. Gojko proposes answering the following:
- Why: Why do we need to introduce this change?
- Who: Who is going to be affected by the change?
- What: What is it?
- How: How is going to impact the business?
More information can be read in his latest book, Impact Mapping.
Niels Malotaux said that about 55% of the defects are in the requirements, not in the code. Someone in the room remarked that it is the 70%. So we need to work more in the iteration planning. The aim of testing is to prevent defects, not to find them.
Regarding the team, I will read this book on The Five Dysfunctions of a Team.
I will also read Lisa's & Janet's book, which is something I should have done time ago!
Some refletions on the state of the industry
Pretty much every keynote talked about the past. Nothing we are doing now is new, many things come from the 50's (some of them even before) and later decades. So it's important to leverage what we learned in the past avoiding the same mistakes again and again. I would summarize the current status of the agile software movement in the first sentence of the manifesto: Individuals and interactions over processes and tools.
Although some attendees expected more technical talks with tools on them, the majority of speakers talked about teams, self-coaching, collaboration, communication and design principles.
The Test Lab!
I told Lisa Crispin about my new application, LiveTeamApp. But I made the mistake of not telling her it was still a "beta" version and she tweeted about it faster than light. That encouraged me to just tell everyone about the application Thanks Lisa!
Left to right: Ivan Stepaniuk, James Lyndsay, Carlos Ble, Bart Knaack
After lunch I visited @theTestLab. where I met James Lyndsay and Bart Knaack. Professional testers and great guys. Bart and James spent the whole day in the test lab, just for the sake of serving others. To help and teach people about testing. They didn't attend to keynotes or talks, they just focused on helping people. To me, that says a lot about them. I am happy to have met them. I proposed LiveTeamApp as an additional testing exercise for the lab and they gently accepted the proposal:
Exploratory testing session for LiveTeamapp
The intrepid testers found about 10 usability issues and 2 minor bugs. Big applause for them: Christian Kliebe, Huib Schoots, Simon Morley, Thomas, and my friend Ivan. Does anybody know Thomas' surname? I would like to link to his blog or twitter!
LiveTeamApp might be available for upcoming test labs run by @theTestLab. And is available online for any team that want to use it
Our talk on BDD applied to Javascript solutions
Daniel Maslyn rocks!
Daniel Maslyn is just the best chair you can have as a speaker. Thank you Daniel!
I have to say that being the chair is not easy. I've also been the chair for some talks and... I don't think I did very well (sorry speakers).
I am quite satisfied with our talk. We worked hard on the preparation, we were able to communicate what we meant, and people said it was understandable. So mission complete, thank you attendees! And thank you Ivan for accepting my co-speaker proposal, you talked very well in my opinion.
The slides will be available for download soon. The AgileTestingDays team will send the download details to all conference attendees.
I plan to write a book (this time in English with some help) on the subject, and I think we will be talking about this in more conferences (always updating the contents). If you find the subject interesting and your English is better than mine (easy!) you can collaborate with me in the revision, just contact me please
Looking forward for next year's conference
I highly recommend the Agile Testing Days conference. All the talks I attend to were very well prepared. Speakers presented clearly and the keynotes where fantastic.
It is a great opportunity to meet professionals with different roles and even to find a job. This year Nokia was looking for developers to hire and the information could be found at their exhibitor in the hall. So much value from a single conference.
Hope to see you there next year!