How to write Data Driven tests in Javascript

I know how to write "Parameterized tests" in Java and Data Driven tests in Groovy using Spock framework. But how to write in JavaScript? Now I try to show how to make it working using mocha framework.

Data Driven tests in Mocha is called "Dynamically generated tests", based on the API documentation, there are 2 steps:
  1) Create a test data array;
  2) Iterate the test data, generate the test case dynamically,  the test case name in "it" block is also generated dynamically, which is quite similar with Spock framework.

The implementation is pretty straight forward. Here is the example of my implementation in the Tennis Game Kata:
  https://github.com/stevez/TennisGame-solution/blob/master/javascript/test/Tennis-test.js

	var assert = require("chai").assert;
	var TennisGame = require("../src/TennisGame");
	describe('Tennis Score', function() {
	var tests = [
	[0, 0, "Love-All"],
	[1, 1, "Fifteen-All"],
	[2, 2, "Thirty-All"],
	[3, 3, "Deuce"],
	[4, 4, "Deuce"],
	[0, 1, "Love-Fifteen"],
	[1, 0, "Fifteen-Love"],
	[0, 2, "Love-Thirty"],
	[2, 0, "Thirty-Love"],
	[0, 3, "Love-Fourty"],
	[3, 0, "Fourty-Love"],
	[0, 4, "Win for player2"],
	[4, 0, "Win for player1"],
	[4, 1, "Win for player1"],
	[1, 4, "Win for player2"],
	[4, 2, "Win for player1"],
	[2, 4, "Win for player2"],
	[4, 3, "Advantage player1"],
	[3, 4, "Advantage player2"],
	[5, 4, "Advantage player1"],
	[4, 5, "Advantage player2"],
	[15, 14, "Advantage player1"],
	[14, 15, "Advantage player2"],
	[6, 4, "Win for player1"],
	[4, 6, "Win for player2"],
	[16, 14, "Win for player1"],
	[14, 16, "Win for player2"]
	];
	function checkScore(pointPlayer1,pointPlayer2) {
	var game = new TennisGame("player1","player2");
	updateScore(game,"player1", pointPlayer1);
	updateScore(game,"player2", pointPlayer2);
	return game.getScore();
	}
	function updateScore(game,name,point) {
	for(var i=0; i<point; i++) {
	game.wonPoint(name);
	}
	}
	tests.forEach(function(test) {
	it(test[0] + ':' + test[1] + '-> ' + test[2], function() {
	var result = checkScore(test[0], test[1]);
	assert.equal(result, test[2]);
	});
	});
	});

view raw Mocha data driven tests hosted with ❤ by GitHub

 The javascript example project is here:
 https://github.com/stevez/TennisGame-solution/tree/master/javascript

Next step I will look at how to work it using Jasmine framework.

Debug Karma Unit tests using visual Studio code

Debugging JavaScript is not easy, especially outside the browser.

VS Code is so powerful for JavaScript debugger. I managed to get it working under Jasmine/Karma unit tests.

Pre-Requisite

• Install the karma chrome-launcher to your project
• Install the vs code chrome debugger extensions

Steps

1.  Config your kama.conf.js, make sure you can launch chrome with remote-debugging-port 9222
   Add the following in to your karma.conf.js

   1 2 3 4 5 6

   customLaunchers: {       Chrome_with_debugging: {         base: 'Chrome',         flags: ['--remote-debugging-port=9222']       }  },

2. Launch the browser custom launcher through gulp task, also we need to disable the JavaScript preprocessors, which purpose is magnifying for the test coverage
   gulp script

   1 2 3 4 5 6 7 8 9 10 11 12 13

   gulp.task('debug-karma', function (done) {   new Server({     configFile: __dirname + '/karma.conf.js',     browsers: ['Chrome_with_debugging'],     preprocessors: {           'components/**/*.js': [],           'lib/crl/**/*.js' : [],           'lib/rapidlab/**/*.js' : []     },     singleRun: false,     autoWatch: true,   }, done).start(); });

3. Update launch.json file in the .vscode folder
   launch.json

   {     "version": "0.2.0",     "configurations": [         {             "name": "Launch Karma debug page",             "type": "chrome",             "request": "launch",             "url": "http://localhost:9876/debug.html",             "sourceMaps": false,             "webRoot": "${workspaceRoot}/src/main/webapp"         },         {             "name": "Attach without source map",             "type": "chrome",             "request": "attach",             "port": 9222,             "sourceMaps": false,             "webRoot": "${workspaceRoot}"         }     ] }

4. In the IDE, run task debug-karma, make sure the chrome browser is launched.
5. Click the Debugger button,select Chrome, choose "Attach without source map", click start button
6. Refresh chrome browser, or in the debugger console, type 
   location.reload();

Sample Project  

Please check this sample JavaScript project: https://github.com/stevez/KataFizzBuzz/tree/master/javascript

You can import this project to launch the chrome debugger inside your VS Code IDE.

Resources

1. http://bahmutov.calepin.co/debugging-karma-unit-tests.html
2. https://github.com/Microsoft/vscode-chrome-debug
3. https://github.com/karma-runner/karma-chrome-launcher

Debug Mocha tests using Visual Studio Code IDE

It is amazing that we could easily debug Mocha javascript test code in Visual studio Code IDE.
Here is the launch.json file:

	{
	"version": "0.2.0",
	"configurations": [
	{
	"name": "Debug mocha",
	"type": "node",
	"request": "launch",
	"program": "${workspaceRoot}/node_modules/mocha/bin/_mocha",
	"stopOnEntry": true,
	"args": [],
	"cwd": "${workspaceRoot}",
	"runtimeExecutable": null,
	"env": { "NODE_ENV": "production"}
	}
	]
	}

view raw launch.json hosted with ❤ by GitHub

Click the Debug button, press F5, then you will see the debugger running.
The detail file is also in github:
https://github.com/stevez/kata-Yatzy-solution/blob/master/javascript/.vscode/launch.json

You can check my sample code in github for details:
 https://github.com/stevez/kata-Yatzy-solution/tree/master/javascript

Some thoughts about Toronto Agile Open space 2016

Here I just try to write down some of my thoughts about yesterday's Toronto Agile Open Space
1. I did another session: it was about the theory of constraints thinking process, I love it because I believe it will bring Agile community 2 important things: Scientific method  and problem solving tools. At the beginning I feel it might be too dry, but Shawn Button and Thanou encouraged me and told me it might be intersting, so I picked one empty space, and lobbied Thanou joined my session, and later 3 more audience showed up (Jim Rootham, Lee from Intelliware and an other TOC guy). I explained them the overview about the 5 thinking process diagram, looked like they got some ideas.
This is the the over view of the TOC thinking process I hand out to the audiences. all my talks are based on it.

 What I learned from this is Just Do It - there is no bad topic or good topics, as long as some one attend your talks, then it is a good one.
Next step what I need to work on:
 - Trying to practice it in daily work, collect all the scenarios I met and write them down into thinking process diagrams, and hopefully I can give them a name if possible. I assume all the software Scrum team will have similar issues I faced, if I created my diagrams, then it will more likely become a general solutions.
 - Share with other Agile coaches.

2. The most important thing I feel so pleased is there are more topics about technical side, for example: Thanou, Peter Yu, Paul, and Shawn Button all facilitated excellent sessions. I really appreciate them drew so many attentions. Also I was surprised that I met a lot more developers in the conference than before. This is definitely a good sign that technical side of agile is resurrecting.
This finding definitely inspired me to focus on the technical side of Agile. In future I will focus on my work on the growing Agile developers. If I have a chance to bring talks in future, my topics will focus on:
- What are the essential skills for the Agile Developers?
- How to become the a successful Agile developers?
- Transform from geek to technical leader
- Create Developers Guild and mentor ship in Scotia bank.
-  Software craftsmanship movement: define the ethics, code of conduct, and disciplines.
- The learning path of a software craftsman
- Mastery: what can we learn from Samaurai, Myamoto Mushashi and Shushi Master?
- Drefus/ Shu-Ha-Ri learning models

- The strategies for refactoring ( Mikado Method for example)

- How to convince people to practice TDD?