Archive for October, 2013



Case study: Audience Response

Wow, AgileTestingDays 2013 it's being awesome! I gave my talk today, a practical "live coding" session. Last week I created a real-time application to communicate with the audience so that when I am speaking they can tell me if they are understanding or if they want me to repeat ...
So we started off using this app on my session. Interestingly enough the session was about building the tool again. From Cucumber specifications, all the way down to the GUI and the hub (server).

You can find the actual code of the application here and more importantly, the process I followed to write it, because I checked-in the code on every green test so by looking at the diffs, you'll figure out how code evolved.
Unfortunately the wifi didn't work well so I couldn't really take advantage of the app. Next time I'll bring my own wireless router to create our private LAN.

In order to prepare the session, I rewrote part of the app again myself. In here you can find this second iteration, again with a test committed at a time. By looking at the commits you can follow part of what I did during my session. You can take the code and practice yourself from this particular commit, comparing your moves with mine ones to see what we can learn.

Find the business specifications of the app here and the step definitions (glue) in here.

Now, the session didn't go bad, but it didn't go as well as I'd like. I did quite bad with the timing.I would have needed 90 minutes rather than 45 to illustrate the process properly. When I was preparing the talk, I wrote the code on my own and it didn't take much time, but presenting it's a different story, I've learned that I need about twice as much time.

2013-10-31 01.24.06But I am satisfied because several people understood the process and got value from it. Next time I run this session, it will go much better. And you know what? I've been approved by The Code Cop! Look at this picture.

 

I'll be happy if you were attending the talk and can give me some feedback in the form of a comment in this blog. As a reward, one person out of the people commenting will be randomly selected and I will run a free 90 minutes session for her/his company (remotely, videoconferencing), doing this same exercise properly with Q&A session.

James Lyndsay and Bart Knaack from The Test Lab have used an instance of the app for testing purposes and people have found several defects. I am happy for that because I didn't do any exploratory testing or even took care of network failures or latency problems. Thanks for that guys!

This exercise will be part of my upcoming book on Agile JavaScript for Rich Internet Applications. I expect to have the book done in 2014.

If you want to have a look at the sample deployed app on Heroku, use these urls:
Load a page in the browser with this url (as a speaker).
Then load the page as the audience in other window.
Then just interact.

Thank you very much for all your support, I really appreciated you invested your time on my talk. If are there questions please let me know of find me tomorrow in the conference to catch up or hang out 🙂

WebSockets and Android

I didn't know that the default browser installed on Android is called Webview. I haven't created any native Android app ever. But I wanted my web app to run on Android using Websockets. Unfortunately, websockets are not implemented in Android Webview.

In modern browsers, HTML5 provides a websocket API:

  1.  
  2. ws = new WebSocket('ws://' + host + ':'+ port);
  3. ws.onmessage = function(msg){
  4. var data = JSON.parse(msg.data);
  5. ws.send(JSON.stringify({message: 'OK cool!'}));
  6. };
  7.  

You don't need to include any JavaScript file in order for this to be valid code in modern browsers (when I saw it for the first time I was like.... "yeah cool but what library are you using?). Well you'd need a Websocket server. I've been trying ws for Node. It works very well with express.js and is very simple:

  1.  
  2. var WebSocketServer = require('ws').Server;
  3. var wss = new WebSocketServer({server: server}); // server is express' server instance.
  4. var clients = [];
  5.  
  6. wss.on('connection', function(ws) {
  7. console.log('connected');
  8. clients.push(ws);
  9. ws.on('close', function(){
  10. console.log('client closing');
  11. });
  12. ws.on('message', function(msg){
  13. console.log('message received');
  14. for (var i = 0, len = clients.length; i < len; i++)
  15. try {
  16. // do not use try-catch here, do it properly
  17. if (clients[i])
  18. clients[i].send(msg);
  19. }
  20. catch(e){
  21. clients[i] = null;
  22. }
  23. });
  24. });
  25.  

The code above is broadcasting a message to all connected clients.

It's very nice but it doesn't work on Android!

Workarounds:

  • Install Firefox or Chrome for Android, they support Websockets
  • Use a library that supports fall back to XHR long polling like Socket.io
  • Use Apache Cordova (phonegap) to create an Android app
  • Use a Flash implementation of websockets

If you use Apache Cordova you need to "provide" the websockets funcionality into webview using Java code. There are several plugins for that:

I haven't used any of those. The disadvantage is that users have to install an application. I just want them to use my web app without installing anything so I've discarded this option.

The flash implementation has some security constraints imposed by flash. I haven't dug into the subject much but I believe I need to open port 843 on the server and I can't do that on some PAAS providers. I can't confirm this, I might be wrong. The other thing is that browser needs the flash plugin. Take a look at this implementation (web-socket-js).

Eventually I've come back to Socket.io. Although people say it's outdated and it's got a poor websockets RFC implementation, it works very well for basic stuff and falls back to XHR long polling automatically:

  1.  
  2. var io = require('socket.io').listen(server); // server is express' server instance
  3. io.configure(function () {
  4. io.set("transports", ["websocket", "xhr-polling"]); // support both
  5. io.set("polling duration", 10);
  6. });
  7.  
  8. io.sockets.on('connection', function(socket){
  9. socket.on("sendMessage", function(msg){
  10. io.sockets.emit("messageReceived", msg); // broadcasting
  11. });
  12. });
  13.  
  14.  

On modern browsers implementing websockets, it will use them. On Android it will just use long polling.

To finish off, just remember that your mobile device and your desktop pc are two separate machines. If your client side js is trying to connect to "localhost" as the websockets server, it's not going to work from your mobile. I know it's absolutely obvious but I wasted more time than I expected not realizing that I had the wrong url in the client side js. It was written "localhost" rather than "192.168.0.100" for my tests using the Local Area Network. It was one of those silly mistakes that steal one's time more than they should 🙁

No long ago in the Spanish TDD mailing list, some friends said they were struggling with test doubles. A typical question is how to use them to design collaboration a la test-first. Test doubles are something people find hard to understand in my TDD training courses.
This is why I've decided to run an online training class on Test Doubles. Mostly those used in unit tests: mocks, stubs and spies.

I'll run two editions of the training, one English spoken and the other Spanish spoken. People can decide which one they want to participate in after they subscribe the online form.

We'll use mostly Java to practice as it's a language most people know. But the same concepts are valid for other languages. We'll also view examples on JavaScript and C#. Like all my training courses, this will be hands-on with very little talk from my side.

The number of participants per course is limited to 25 so that I will have time to review all the exercises during the course and make suggestions. I enjoy having time to share it with participants one by one. Don't wait too much, 25 spots will be gone soon 🙂

As this is the first edition it comes with a special price, only 49 bucks!

If you are familiar with the idea of writing a test first, you can join this class. We'll use Webex for videoconferencing as well as sharing resources together with other tools.

Find the subscription form here.

Fluent API for test doubles

There are several good frameworks out there to create test doubles with JavaScript. Jasmine  and Sinon provide test spies and stubs. JsMockito looks good too. However, creating your own API for test stubs is very easy. I've created mine as an exercise. It's a very naive implementation but it works. See the code:

  1.  
  2. describe("a fluent API to create a test stub", function(){
  3. it("stubs out a method", function(){
  4. // the fluent API:
  5. function when(stub){
  6. return {
  7. thenReturn:function(arg1){
  8. stub.configureOutput(arg1);
  9. }
  10. };
  11. }
  12. function stub(actual){
  13. var expectedArgs,
  14. configuredOutput,
  15. isConfigured = false;
  16. actual.configureOutput = function(output){
  17. configuredOutput = output;
  18. isConfigured = true;
  19. }
  20. actual.someMethod = function(){
  21. if (isConfigured){
  22. if (expectedArgs[0] == arguments[0])
  23. return configuredOutput;
  24. return;
  25. }
  26. else
  27. expectedArgs = arguments;
  28. return actual;
  29. };
  30. return actual;
  31. }
  32.  
  33. // the test confirming it works:
  34. var actualObject = {someMethod: function(a){return 1+a;}};
  35. var theStub = stub(actualObject);
  36.  
  37. when(theStub.someMethod(2)).thenReturn(5);
  38. expect(theStub.someMethod(2)).toBe(5);
  39. });
  40. });
  41.  

The implementation is not generalized to support any method or any number of parameters. I just wanted to play with the idea that I can invoke the stubbed method in the "when" statement and it doesn't execute anything apparently. It only executes the stubbed behavior once it's been configured.

It's very simple but it didn't come up to my mind when I implemented pyDoubles (now Doublex), which might have made the API even better.

Next week, I'll be taking part in the London Tester Gathering Workshops at SkillsMatter. I'll be giving a 4 hours workshop on JavaScript aimed at software testers on Thursday. Inspired by the workshop, I am working on a JavaScript manual for testers (JavaScript4Testers) that will be available soon. The manual will serve as a guide along the workshop and in the future it might become a book, because my friend Tony Bruce is now co-authoring it with me, which is very exciting. The manual contains already some brief sections on the JavaScript language and then it addresses testing techniques, debugging, tools and some tips on performance and security. If you think this manual is looking interesting, please go to its site and write down your name an email, that will encourage us even more.

Like all my workshops, it will be a hands-on session with very little theory and lots of practice. That is how I enjoy running workshops and the way people learn more.

I am a developer, am not a tester. In fact I am terrible at catching defects. But I love working together with testers because I like their vision and their collaboration spirit. Working together is very nice and effective. And I learn techniques on how to break the software by observing them. So I am looking forward to meeting all the participants in what is going to be a great experience. The workshop's atmosphere at SkillsMatter is very friendly, we'll have plenty of time to chat, share experiences, learn and enjoy. This is the Twitter hashtag for this edition: #ltgw2013

I land in London on Wednesday 16 afternoon. To warm up and meet  friends, a bunch of developers will meet in this pub to practice coding (a code kata) at 7pm. Feel free to join us.

See you next week in London 😀