Angel \”Java\” Lopez on Blog

March 18, 2015

Liqueed Project (3)

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

Previous 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) {

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

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) {

    service.getPersonById(annaid, function (err, result) {
        test.equal(, 'Anna');
        test.equal(, annaid);
        test.equal(result.username, 'anna');

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

December 10, 2014

SimpleLisp (2) Compiling Lisp Values and Variables to JavaScript

Previos Post

Let’s review the project’s implementation

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

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) {

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) {

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) {
        if (elsecmd)

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("", test), "");

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

November 25, 2014

SimpleLisp (1) Compiling Lisp to JavaScript

Next Post

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

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:

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

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

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();


        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)

            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.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

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

On-site TDD | My Not So Private Tech Life

My Not So Private Tech Life | Johannes Link’s Travels through Software Development Space

Functional TDD: A Clash of Cultures

Skills Matter

30 Days of TDD: Day One – What is TDD and Why Should I Use It?

TDD: Why We Don’t Party Like It’s 1999

Claysnow Limited – To TDD or not to TDD? That is not the question.


Unit testing AngularJS with Visual Studio, ReSharper and TeamCity | endjin blog

Venkat Subramaniam: Succeeding with TDD: Pragmatic Techniques for effective mocking on Vimeo

Learning TDD Through Test First Teaching – YouTube

Separating Allocation from Code // Speaker Deck

Clean Coder Blog

Skills Matter

Test-driven JavaScript in practice by Christian Johansen at NDC 2011 at Oslo, Norway –

Writing meaningful, self-documenting, behavior-oriented tests – Daniel Cazzulino’s Blog

Software Craftsmen Are Arrogant, Slow, and Dogmatic | 8th Light

My Links

Stay tuned!

Angel “Java” Lopez

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

Moving from Practice to Production with Test-Driven Development

TDD is TDD (And Far From Dead) – Software People Inspiring

A TDD Journey: 1-Trials and Tribulations

A TDD Journey: 2- Naming Tests; Mocking Frameworks; Dependency Injection–naming-tests-mocking-frameworks-dependency-injection/

When TDD Doesn’t Matter

Test-Driven Development… by Grzegorz Gałęzowski [PDF/iPad/Kindle]

Creating and testing Meteor applications with BDD using Velocity and Jasmine | Dr. Llama’s Blog

One Mock Per Test Considered Not Awesome at

Everyday Tales: We Call It Unit For A Reason

Programming Without Fear | The Journeyman Programmer

Applying TDD to Scalding Development |

My Links

Stay tuned!

Angel “Java” Lopez

July 26, 2014

AjKeyvs Implementing Key-Value Store in C# (1) The Project

Filed under: .NET, AjKeyvs, C Sharp, No, NoSQL, Open Source Projects, Test-Driven Development — ajlopez @ 6:40 pm

I want to implement a key-value store (as Redis) in C#, play with data structures, and practice TDD (Test-Driven Development). I started:

The current structure:

There is a class library project, AjKeyvs, that contains the collections in an in-memory repository. The interesting part of this projects is to implement arrays and sets that can be sparse, having different keys. Example, having a key 1 (one) and a key 1000000 (one million) does not imply to have an array with one million positions. At the same, I want to have a good access and update time. In other use cases, I will have string keys, like “user”, “user:1”, “user:1:email”, etc. There are use cases that need the use of sets, with union, intersection, difference, etc… For integer keys, I jave a set where a could turn a bit on or off, for the presence or absense of an element. More implementation details in upcoming post.

The library can be used in-process, but I added a server and a client program. The server listen commands sent by the clientes. All collections reside in memory. Persistence is something orthogonal to the implemented use cases. I should decide if add the persistence into the command processing, or is something to be implemented outside the project.

As usual, I followed TDD workflow.

Next topics: data structures, collections, commands, concurrency, etc.

Stay tuned!

Angel “Java” Lopez

July 13, 2014

SharpBus in C# (1) First Steps

Filed under: .NET, C Sharp, Open Source Projects, SharpBus, Test-Driven Development — ajlopez @ 11:54 am

Last month I started to write SharpBus, a simple message processor inspired by ideas from Mule Java project. See:

As usual, I’m using TDD (Test-Driven Development), implementing small use cases and API consumption, in the simplest possible way. In fact, the project is a personal exercise of TDD. I hope that some may be useful beyond that. For now, it is an example that I want to share my workflow.

You can see the progress in:

The main ideas to implement are:

- There are Messages containing Payloads and Properties (dictionary of name / value)

- There Flows that process messages

- A Flow is composed of several elements

The elements can be chained in the flow, and can be:

- A Transformer, taking a payload or complete message, and returns a transformed version

- A Processor, taking a payload or complete message, operate on them, maybe accessing the business domain, but without transformation

- Input, a payload/message producer

- Output, a payload/message consumer, at the end od the Flow process

- A Rourter, given a payload/message, it decides with Branch to follow in the Flow. Each Branch is identified by a name.

There will also be items that can issue new posts than the current, and can issue them to different flows in the system. The message producers should be able to run threads (Threads) in principle. And there will be a set of threads (Pool of Threads) attending the incoming messages and deriving them to the respective flows.

A flow can take a message and return a response (Request / Response), or it can take a message, process it without returning an answer.

Some items need complete Message and other items operate over the Payload.

The elements in the world of Mule / Java are objects. Notably, in C #, the simplest way to implement is using lambdas. So, following TDD, the early testing and deployment has come out that way. You can see in some simple tests:

As an example of send a Payload and receive an answer, using an empty Flow:

var flow = Flow.Create();

Assert.AreEqual(1, flow.Send(1));

To send a payload and transform it:

var flow = Flow.Create()
    .Transform(x => ((int)x) + 1);

Assert.AreEqual(2, flow.Send(1));

The .Transform Transform expects a Func<object, object> which may be provided at the time with a lambda. In a classic Java 7 Mule, we should provide an object that implements an interface having a method to transform the Payload. I have to think whether it is worth having a typed Transform <T> (receiving T and returns T), or Transform <T, S> (receiving and returns T S).

I decided to build the flow by code. In the Mule environment Spring is used to set up the flow using XML. I think it is time to explore this other way, build the flow by code, and put it as the "first way", ie, as the way on which everything else could be mounted. If anyone ever needed a DSL (Domain-Specific Language) for creating flows could be implemented this way by having well designed code.

Following TDD, I still have not a case of using a Message (a complete message with content (Payload) and properties (Properties, a name / value) dictionary. All of the above is to process Payload directly.

Upcoming topics: add Message Payload with the output of messages, routing, assembling branches, etc. ..

Stay tuned!

Angel “Java” Lopez

July 6, 2014

TDD: Links, News And Resources (22)

Previous Post
Next Post

Myron Marston » Thoughts on Mocking

Why Your Test Suite Sucks – YouTube

Detecting Changes in Third-Party Code – The Code Whisperer

Justin Searls: JavaScript Testing Tactics on Vimeo

TDD by example: Patterns | Nico Cortés blog

Steve Freeman On TDD: How Do We Know When We’re Done?

Unit Testing JavaScript Applications

Scan Agile 2012: Phil Calçado: Better Functional Design Through Test-Driven Development on Vimeo

The TDD That Can be Spoken Is Not the Eternal TDD

The Domain Discontinuity | 8th Light

Test Double | Our Thinking | The Failures of “Intro to TDD”

¿Está TDD muerto o más vivito y coleando que nunca? – YouTube

TDD en C# con Visual Studio y NUnit – YouTube

Learn Test Driven Development in Flask – Part 2 | /dev/notes

Python: Automated Testing with Grunt (Node.js) | /dev/notes

Tom Stuart on TDD, BDD and Ruby

Test-Driven Development by Kent Beck

e-ferro Venturas/Desventuras de “informático”: De Test Unitarios de clases a Tests Unitarios de funcionalidad, un gran paso

JUnit: A Cook’s Tour

You won’t believe how old TDD is | Arialdo Martini

(10) Learning About TDD: The Purpose of #isTDDDead

Test Isolation Is About Avoiding Mocks — Destroy All Software Blog

Mis impresiones sobre el debate #isTDDDead | Jose Armesto

My Links

Stay tuned!

Angel “Java” Lopez

Older Posts »

The Shocking Blue Green Theme. Create a free website or blog at


Get every new post delivered to your Inbox.

Join 69 other followers