Angel \”Java\” Lopez on Blog

April 25, 2015

Liqueed Project (6)

Filed under: Express, JavaScript, Liqueed, NodeJs, Test-Driven Development — ajlopez @ 4:26 pm

Previous Post

Let review another tests from test/personapi.js in project:

https://github.com/liquid-co-ops/liqueed

There are API entrypoints that are called using PUT or POST. They receive data in the body of the sent message. Using Express middleware, that message (formatted as JSON) is analized, parsed and converted into a JavaScript object. That object resides in the body property of the received request parameter. As the API uses that field, we should provide it in the test. An example:

exports['login person'] = function (test) {
    test.async();
    
    var request = {
        body: {
            username: persons[1].username,
            password: persons[1].username
        }
    };

    var response = {
        send: function (model) {
            test.ok(model);
            test.equal(model.id, persons[1].id);
            test.equal(model.name, persons[1].name);
            test.equal(model.username, persons[1].username);
            
            test.done();
        }
    };
    
    controller.loginPerson(request, response);
};

As in the previous example, we use the send function in the response object, to check the result.

Another example, sending not only the body but also sending parameters:

exports['change password first person'] = function (test) {
    test.async();
    
    var request = {
		params : {
			id : persons[0].id.toString()
		},
        body: {
            password: 'new' + persons[0].username
        }
    };

    async()
    .then(function (data, next) {
        var response = {
            send: function (model) {
                test.ok(model);
                test.strictEqual(model, true);
                
                next(null, null);
            }
        };
        
        controller.updatePassword(request, response);
    })
    .then(function (data, next) {
        var request = {
            body: {
                username: persons[0].username,
                password: 'new' + persons[0].username
            }
        };

        var response = {
            send: function (model) {
                test.ok(model);
                test.equal(model.id, persons[0].id);
                test.equal(model.name, persons[0].name);
                test.equal(model.username, persons[0].username);
                
                test.done();
            }
        };
        
        controller.loginPerson(request, response);
    })
    .run();
};
 

Next posts: MVC controller actions tests, tests launching the HTTP server, tests using a DSL (Domain-Specific Language)

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

April 20, 2015

Liqueed Project (5)

Filed under: Express, Liqueed, NodeJs, Test-Driven Development — ajlopez @ 5:38 pm

Previous Post  
Next Post

Let review two more tests from test/personapi.js. The second test is actually:

exports['get persons'] = function (test) {
    test.async();
    
    var request = {};
    var response = {
        send: function (model) {
            test.ok(model);
            test.ok(Array.isArray(model));
            test.ok(model.length);
            test.ok(model[0].id);
            test.ok(model[0].name);
            test.done();
        }
    };
    
    controller.list(request, response);
};

After building the domain model in memory (the first test taks), now we can test a controller action method, named getPersons. It requires to receive two arguments, request and response object. In the above code, two stubs were built and used. The response object has a send function that  it should be invoked to pass the tests. It receives the model to send to the client, as a JavaScript object (in the real environment, the object is serialized to JSON via Express response send method).

The third test is:

exports['get first person'] = function (test) {
    test.async();
    
    var request = {
        params: {
            id: persons[0].id.toString()
        }
    };

    var response = {
        send: function (model) {
            test.ok(model);
            test.equal(model.id, persons[0].id);
            test.equal(model.name, persons[0].name);
            test.done();
        }
    };
    
    controller.get(request, response);
};

The action needs something from request object, an aditional argument having the person primary key to be retrieved. There is a send method in request object, to test the result.

The tests are not using HTTP nor GET method. They are directly testing the controller code. Indeed, that code was written AFTER the tests, and its first execution was from test launch, without the need of launch a web server.

Next posts: other tests for API methods, sending objects, and tests for MVC controllers

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

April 15, 2015

Liqueed Project (4)

Filed under: Express, JavaScript, Liqueed, NodeJs, Test-Driven Development — ajlopez @ 8:42 pm

Previous Post
Next Post

The project:

https://github.com/liquid-co-ops/liqueed

was built using TDD (Test-Driven Development) worflow. In the previous post I showed a logic service example, implemented using tests. Today, I want to show that the MVC controllers was also coded using TDD. The controllers are JavaScript modules that expose functions as actions to be routed by Express. The actions receive and return JSON objects. They are the basis for the exposed API, to be consumed by the clients (actually, only one client, a simple single page application). For example, controllers\personapi.js starts declaring:

'use strict';

var service = require('../services/person');

It consumes the person service module.

There are associated test at test\personapi.js, its initial imports:

'use strict';

var controller = require('../controllers/personapi');

var loaddata = require('../utils/loaddata');
var db = require('../utils/db');
var async = require('simpleasync');

In the previous post, I mentioned that the test granularity I prefer for JavaScript is the module, not the function. So, all the tests in the module are execute, in declaration order. The first test is in charge of inicialization the domain model:

var persons;

exports['clear and load data'] = function (test) {
    var personService = require('../services/person');

    test.async();
    
    async()
    .then(function (data, next) { db.clear(next); })
    .then(function (data, next) { loaddata(next); })
    .then(function (data, next) { personService.getPersons(next); })
    .then(function (data, next) {
        persons = data;
        test.ok(persons);
        test.ok(persons.length);
        test.done();
    })
    .run();
};

The new thing to understand is the use of the module simpleasync, pointed by the async variable. I wrote the module to chain  functions. Each function receives two arguments: data, the success result of the previous executed function in chain, or the initial value triggered in the run chain function. And next, a callback to be invoked by the function, to execute the rest of the chain. The callback receives two arguments: err and data. So it can be used as the callback of other functions. If err is not null, the next functions in chain is not executed and the function defined in the chain fail method is run (this option is not used in the above code). In the above example  personService.getPersons(next) invokes the retrieve of the person list, using next as callback. The next chained function receives the person list in the data argument, and then, it saves it in a module variable, ready to be used by the rest of the tests.

It is not using a database. It using an in-memory domain model. That is the default “persistence”, and it is used in many of the defined tests. The initial domain model is loaded from testdata.json using the loaddata function:

{
    "projects": [
        {
            "name": "FaceHub",
            "periods": [
                { 
                    "name": "January 2014", 
                    "date": "2014-01-31", 
                    "amount": 100,
                    "assignments": [
                        { "from": "Alice", 
                            "to": "Bob", 
                            "amount": 50, 
                            "note": "Arrive earlier" },
                        { "from": "Alice", 
                            "to": "Charlie", 
                            "amount": 50 , 
                            "note": "Arrive earlier" },
                        { "from": "Bob", 
                            "to": "Alice", 
                            "amount": 60 , 
                            "note": "Arrive earlier" },
                        { "from": "Bob", 
                            "to": "Charlie", 
                            "amount": 40 , 
                            "note": "Arrive earlier" },
                        { "from": "Charlie", 
                            "to": "Alice", 
                            "amount": 35 , 
                            "note": "Arrive earlier" },
                        { "from": "Charlie", 
                            "to": "Bob", 
                            "amount": 65 , 
                            "note": "Arrive earlier" }
                    ]
                },
                { "name": "February 2014", 
                    "date": "2014-02-28", 
                    "amount": 100 }
            ],
            "team": [ "Alice", "Bob", "Charlie" ],
//....

The module personapi.js exports some functions to be used as actions:

module.exports = {
    list: list,
    get: get,
    getProjects: getProjects,
    loginPerson: loginPerson,
    getPendingShareProjects:getPendingShareProjects,
    updatePassword: updatePassword
}

Topics for the next posts: more API tests, routing of actions, persistence, etc.

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

March 18, 2015

Liqueed Project (3)

Filed under: Express, JavaScript, Liqueed, NodeJs, Test-Driven Development — ajlopez @ 5:24 pm

Previous Post
Next Post

I’m a big supporter of TDD (Test-Driven Development), and its workflow for software development. The software is created based on the tests that describe the expected behaviour, using the simplest possible implementation. For Liqueed Project, TDD was adopted during the creation of most of the code.

An example: there is a file, services\person.js, that is a JavaScript module. It manages the logic of the persons. A person can participate in zero, one or more projects, have sharepoints, vote, etc. And the system keeps the list of persons, retrieve a person by id, by username, … Part of the logic is in the service module. It was written using test/person.js for the tests of the logic. One test, one impementation, refactor, and so on. At the beginning of the test mode, there are some requires:

'use strict';

var service = require('../services/person');
var pservice = require('../services/project');
var async = require('simpleasync');

The services persons and project are used. simpleasync is a simple module I wrote to chaining callbacks. It was an interesting experience, and I’m doing “dog-fooding” in many projects.

Then, two module variables are declared, to be reused in the tests. They are the ids of some persons:

var annaid;
var lauraid;

To run the tests, I’m using simpleunit, another module I wrote, again, to practice JavaScript, TDD and simplicity. It is inspired by nodeunit, but it is simpler. simpleunit executes the module exported functions, providing a test object, something alike to assert in NodeJs.

The first tests exercises the creation of a person:

exports['add person'] = function (test) {
    test.async();

    service.addPerson({ name: 'Anna' }, function (err, result) {
        test.ok(!err);
        test.ok(result);
        annaid = result;
        test.done();
    });
};

It has a callback, so the function could end BEFORE the creation of the person. So, the test.async() tells to simpleunit to wait until the test.done() is reached. The above test only check the return of an id for the new person, and the value is saved in a module variable. This is something to discuss, but I found this way an easy one. The second tests depends on the first one. In C#, in other technologies, I wrote more isolated tests. But for me, in JavaScript, the level of isolation is the module, not the test function. In a module, a test function could depend on the execution of a previous one.

The second test:

exports['get person by id'] = function (test) {
    test.async();

    service.getPersonById(annaid, function (err, result) {
        test.ok(!err);
        test.ok(result);
        test.equal(result.name, 'Anna');
        test.equal(result.id, annaid);
        test.equal(result.username, 'anna');
        test.done();
    });
};

Using the id generated by the first test, the person is retrieved, and the data is checked.

This test series doesn’t use a predefined domain, and it does not assume a previous well-knoen status. And these tests are implemented using an in-memory domain. In the initial iterations, this in-memory domain was the only implementation. Only after the implementation of the first big use case, we added a domain persisted in MongoDB.

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

December 10, 2014

SimpleLisp (2) Compiling Lisp Values and Variables to JavaScript

Previos Post

Let’s review the project’s implementation

https://github.com/ajlopez/SimpleLisp

the Lisp compiler to JavaScript, written in JavaScript, following the workflow of TDD (Test-Driven Development). All is “work in progress”, so today I will explain part of the implementation but it could be change in the future, when new use cases were added, and new ways of doing things were implemented.

I took the decision that each Lisp symbol is a JavaScript variable. So, the compilation of a symbol is:

exports['compile symbol'] = function (test) {
    test.equal(sl.compile('a'), 'a');
}

The sl is the SimpleLisp module, loaded in this test file (test/compile.js)

An integer and an string are compiled to natural values in JavaScript:

exports['compile integer'] = function (test) {
    test.equal(sl.compile('42'), '42');
}

exports['compile string'] = function (test) {
    test.equal(sl.compile('"foo"'), '"foo"');
}

It’s quoted values, too:

exports['compile quoted integer'] = function (test) {
    test.equal(sl.compile("'42"), '42');
}

exports['compile quoted string'] = function (test) {
    test.equal(sl.compile("'\"foo\""), '"foo"');
}

I decided to compile Lisp nil to JavaScript null. The boolean values are the same:

exports['compile nil'] = function (test) {
    test.equal(sl.compile('nil'), 'null');
}

exports['compile booleans'] = function (test) {
    test.strictEqual(sl.compile('false'), 'false');
    test.strictEqual(sl.compile('true'), 'true');
}

But, what happens if an expression serie is compiled? I build an anonymous function, invoked without arguments, and the last expression value is returned:

exports['compile two symbols'] = function (test) {
    test.equal(sl.compile('a b'), '(function () { a; return b; })()');
}

Next topics: compilation of a Lisp lisp, and more quoted values, macros, ect.

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

November 28, 2014

SimpleScript (3) The Parser, Expressions and Commands

Previos Post

Let’s visit the Parser, that is a separated module. It starts with a simple declaration:

'use strict';

var lexer;

if (typeof lexer == 'undefined')
    lexer = require('./lexer');

var parser = (function () {
    var TokenType = lexer.TokenType;
    var binoperators = [ "+", "-", "*", "/", "==", "!=", "<", ">", "<=", ">=" ];

It uses and requires the lexer module. After this declaration, there are many expressions and commands. This is the expression “class” for a name (ie, foo):

function NameExpression(name) {
    this.isLeftValue = true;

    this.compile = function () {
        return name;
    };

    this.getName = function () {
        return name;
    }

    this.collectContext = function (context) {
        context.declare(name);
    }
}

In an upcoming post, I will describe the detection and construction of commands and expression. An expression should implement two methods: compile, that returns an string with the compiled JavaScript code associated to the expression, and collectContext, that allows the discover of used variables in an expression/command. In the above code, NameExpression declares its name to a context, an object that is recovering the used variables.

This is an IndexedExpression, composed by an expression and another one for the index (it’s like foo[42+1]):

function IndexedExpression(expr, indexpr) {
    this.isLeftValue = true;

    this.compile = function () {
        return expr.compile() + '[' + indexpr.compile() + ']';
    };

    this.collectContext = function (context) {
        expr.collectContext(context);
    }
}

The collectContext visits the internal expression (I could add the visit of the index expression, too).

There are commands, like IfCommand:

function IfCommand(cond, thencmd, elsecmd) {
    this.compile = function () {
        var code = 'if (' + cond.compile() + ') { ' + thencmd.compile() + ' }';
        if (elsecmd)
            code += ' else { ' + elsecmd.compile() + ' }';
        return code;
    };

    this.collectContext = function (context) {
        cond.collectContext(context);
        thencmd.collectContext(context);
        if (elsecmd)
            elsecmd.collectContext(context);
    }
}

The distinction between commands and expressions is a formal one. Again, a command should implement compile and collectContext. The above code generates a JavaScript if command.

As usual, I followed TDD (Test-Driven Development) workflow. Partial tests example:

exports['Compile string without quotes inside'] = function (test) {
    test.equal(compileExpression("'foo'", test), "'foo'");
    test.equal(compileExpression('"foo"', test), "'foo'");
}

exports['Compile name'] = function (test) {
    test.equal(compileExpression("foo", test), "foo");
}

exports['Qualified name'] = function (test) {
    test.equal(compileExpression("foo.bar", test), "foo.bar");
}

exports['Indexed term'] = function (test) {
    test.equal(compileExpression("foo[bar]", test), "foo[bar]");
}

Remember: No TDD, no paradise! ;-)

Next topics: how to recognize and build expressions and commands.

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

November 25, 2014

SimpleLisp (1) Compiling Lisp to JavaScript

Next Post

I implemented Lisp as interpreter, using C#, Java, and JavaScript. See:

https://github.com/ajlopez/AjLisp
https://github.com/ajlopez/AjLispJava
https://github.com/ajlopez/AjLispJs

The implementation of a Lisp is a good programming exercise. Lisp is a simple and powerful language, with functions as first class citizens. And with the “twist” of implementing functions that don’t evaluate their arguments, and macros.

This time, I want to implement a Lisp, but as a compiler. I started to write a Lisp compiler in JavaScript, that generates JavaScript. The project:

https://github.com/ajlopez/SimpleLisp

As usual, I worked using the Test-Driven Development workflow. With simple use cases, I implemented the needed features. This is my first Lisp compiler, so I’m trying new implementation approaches. I know Clojure, as a basis for a Lisp compiler. I should implement:

Symbols: identifiers witn name and associated value. Now, I’m compiling them to JavaScript variables. In SimpleLisp, a symbol can be defined at top, in a let block, or as a function argument. Then, I produce a top variable (or a least, a module variable), or a local variable in let, or an argument in function.

Functions: I’m translating a normal function in Lisp to a normal function in JavaScript. The main difference is that Lisp functions returns a value, there are no commands, all are expression, as in Ruby. A list in SimpleLisp is then compiled to a function call in JavaScript.

Special Forms: Their implementation is a novelty to me. In a compiler, I could generate directly the final code for each list with a head that is an special form. So, I’m compiling directly to JavaScript any list with head if, do, let, etc… . A list (if ….) is compiled to a JavaScript if, but returning a value.

Macros: In a compiler, I could adopt a new implementation: to expand the macro at COMPILING TIME. I’m not sure yet if I can take this approach in every case. Notably, in Clojure a macro is not a functional value: a macro cannot be passed as an argument. A macro make sense only at compiling time.

A final use case: write a web site using Node.js/Express in SimpleLisp.

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

November 11, 2014

SimpleScript (2) The Lexer

Previous Post
Next Post

These days, I was working improving my SimpleScript compiler to JavaScript. Today, I want to comment the implementation of the lexer, the repo is

http://github.com/ajlopez/SimpleScript

Now, the lexer code resides in a dedicated file lib/lexer.js, that expose a module, that can be consumed from Node.js and from the browser. It starts defining the token types:

var lexer = (function () {
    var TokenType = { 
        Name: 1, 
        Integer: 2, 
        Real: 3, 
        String: 4, 
        NewLine: 5, 
        Separator: 6, 
        Assignment: 7 };

Then, it defines some operatores, delimiters, and the Token, with two elements, type and value.

var separators = ".,()[]";
var assignments = ["=", "+=", "-=", "*=", "/="];
var operators = ["+", "-", "*", "/", "==", "!=", "<", ">", "<=", ">="];

function Token(value, type) {
    this.value = value;
    this.type = type;
}

The main job is in the Lexer “class”, with the method nextToken:

function Lexer(text) {
    var length = text ? text.length : 0;
    var position = 0;
    var next = [];

    this.nextToken = function () {
        if (next.length > 0)
            return next.pop();

        skipSpaces();

        var ch = nextChar();

        if (ch === null)
            return null;

        if (ch === '"' || ch === "'")
            return nextString(ch);

        if (ch === '\n')
            return new Token(ch, TokenType.NewLine);

        if (ch === '\r') {
            var ch2 = nextChar();

            if (ch2 === '\n')
                return new Token(ch + ch2, TokenType.NewLine);

            if (ch2)
                pushChar(ch2);

            return new Token(ch, TokenType.NewLine);
        }

        if (isAssignment(ch))
            return new Token(ch, TokenType.Assignment);

        if (isOperator(ch))
            return nextOperator(ch);

        if (isSeparator(ch))
            return new Token(ch, TokenType.Separator);

        if (isFirstCharOfName(ch))
            return nextName(ch);

        if (isDigit(ch))
            return nextInteger(ch);
    }

Finally, the module expose a lexer factory and the enumeration of token types:

return {
    lexer: function (text) { return new Lexer(text); },
    TokenType: TokenType
}

The code was developed using Test-Driven Development workflow. There is a file test/lexer.js, fragment:

function getToken(text, value, type, test) {
    var lexer = sslexer.lexer(text);
    var token = lexer.nextToken();
    test.ok(token);
    test.equal(token.value, value);
    test.equal(token.type, type);
    test.equal(lexer.nextToken(), null);
};

exports['Get names'] = function (test) {
    getToken('foo', 'foo', TokenType.Name, test);
    getToken('foo123', 'foo123', TokenType.Name, test);
    getToken('foo_123', 'foo_123', TokenType.Name, test);
    getToken('_foo', '_foo', TokenType.Name, test);
}

exports['Get integer'] = function (test) {
    getToken('123', '123', TokenType.Integer, test);
    getToken('1234567890', '1234567890', TokenType.Integer, test);
}

Remember: no TDD, no paradise ;-)

Next topics: the parser, commands and expressions implementations, compilation to JavaScript.

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

October 29, 2014

TDD: Links, News And Resources (24)

Filed under: Agile Software Devevelopment, Links, Test-Driven Development — ajlopez @ 7:08 pm

Previous Post

Test-Driven JavaScript with Jasmine
http://www.infoq.com/presentations/jasmine-unit-tests-javascript

On-site TDD | My Not So Private Tech Life
http://blog.johanneslink.net/2014/08/01/on-site-tdd/

My Not So Private Tech Life | Johannes Link’s Travels through Software Development Space
http://blog.johanneslink.net/

Functional TDD: A Clash of Cultures
https://m.facebook.com/notes/kent-beck/functional-tdd-a-clash-of-cultures/472392329460303

Skills Matter
https://skillsmatter.com/skillscasts/2300-fractal-tdd-using-tests-to-drive-system-design

30 Days of TDD: Day One – What is TDD and Why Should I Use It?
http://blogs.telerik.com/james-bender/posts.aspx/13-09-09/30-days-tdd-day-one-what-is-tdd

TDD: Why We Don’t Party Like It’s 1999
http://www.infoq.com/presentations/tdd-variants

Claysnow Limited – To TDD or not to TDD? That is not the question.
http://claysnow.co.uk/to-tdd-or-not-to-tdd/

gotwarlost/istanbul
https://github.com/gotwarlost/istanbul

Unit testing AngularJS with Visual Studio, ReSharper and TeamCity | endjin blog
http://blogs.endjin.com/2014/09/unit-testing-angularjs-with-visual-studio-resharper-and-teamcity/

Venkat Subramaniam: Succeeding with TDD: Pragmatic Techniques for effective mocking on Vimeo
http://vimeo.com/68383352

Learning TDD Through Test First Teaching – YouTube
https://www.youtube.com/watch?v=KgfdlZuVz7I

Separating Allocation from Code // Speaker Deck
https://speakerdeck.com/chrismdp/separating-allocation-from-code

Clean Coder Blog
http://blog.cleancoder.com/uncle-bob/2014/09/03/TestTime.html

Skills Matter
https://skillsmatter.com/skillscasts/1768-javascript-tdd-workshop-using-jasmine-to-test-drive-your-javascript-application

Test-driven JavaScript in practice by Christian Johansen at NDC 2011 at Oslo, Norway – EveryTalk.tv
http://www.everytalk.tv/talks/693-NDC-Test-driven-JavaScript-in-practice

Writing meaningful, self-documenting, behavior-oriented tests – Daniel Cazzulino’s Blog
http://blogs.clariusconsulting.net/kzu/writing-meaningful-self-documenting-behavior-oriented-tests/

Software Craftsmen Are Arrogant, Slow, and Dogmatic | 8th Light
http://blog.8thlight.com/paul-pagel/2014/08/21/software-craftsmen-are-arrogant-slow-and-dogmatic.html

My Links
http://delicious.com/ajlopez/tdd

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

September 18, 2014

TDD: Links, News And Resources (23)

Previous Post
Next Post

Lo que los gurús nunca te cuentan sobre Kanban y SCRUM
http://www.programania.net/desarrollo-agil/lo-que-los-gurus-nunca-te-cuentan-sobre-kanban-y-scrum/

Moving from Practice to Production with Test-Driven Development
https://www.simple-talk.com/dotnet/.net-framework/moving-from-practice-to-production-with-test-driven-development/

TDD is TDD (And Far From Dead) – Software People Inspiring
http://codemanship.co.uk/parlezuml/blog/?postid=1240

A TDD Journey: 1-Trials and Tribulations
https://www.simple-talk.com/dotnet/.net-framework/a-tdd-journey-1-trials-and-tribulations/

A TDD Journey: 2- Naming Tests; Mocking Frameworks; Dependency Injection
https://www.simple-talk.com/dotnet/.net-framework/a-tdd-journey-2–naming-tests-mocking-frameworks-dependency-injection/

When TDD Doesn’t Matter
https://www.facebook.com/notes/kent-beck/when-tdd-doesnt-matter/797644973601702

Test-Driven Development… by Grzegorz Gałęzowski [PDF/iPad/Kindle]
https://leanpub.com/tdd-ebook

Creating and testing Meteor applications with BDD using Velocity and Jasmine | Dr. Llama’s Blog
https://doctorllama.wordpress.com/2014/08/03/creating-and-testing-meteor-applications-with-bdd-using-velocity-and-jasmine/

One Mock Per Test Considered Not Awesome at PhilCalcado.com
http://philcalcado.com/2010/12/14/one-mock-per-test-considered-not-awesome/

Everyday Tales: We Call It Unit For A Reason
http://philcalcado.com/2010/06/07/everyday_tales_we_call_it_unit_for_a_reason.html

Programming Without Fear | The Journeyman Programmer
http://teamdoty.us/journeymanwp/?p=22

Applying TDD to Scalding Development | Scalding.io
http://scalding.io/2014/07/applying-tdd-to-scalding-development/

My Links
http://delicious.com/ajlopez/tdd

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Older Posts »

The Shocking Blue Green Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 68 other followers