TITLE: Test-First Development and Implementation of Processing.js
AUTHOR: Eugene Wallingford
DATE: June 25, 2012 12:11 PM
DESC:
-----
BODY:
While describing the lessons learned by the team that wrote
Processing.js,
Mike Kamermans talks about one of the benefits of writing
tests before writing code:
The usual process, in which code is written and then test
cases are written for that code, actually creates biased
tests. Rather than testing whether or not your code does
what it should do, according to the specification, you are
only testing whether your code is bug-free. In Processing.js,
we instead start by creating test cases based on what the
functional requirements for some function or set of functions
is, based on the documentation for it. With these unbiased
tests, we can then write code that is functionally complete,
rather than simply bug-free but possibly deficient.
When you implement a language processor, you can use the
language specification as a primary guide. Testing your code
efficiently, though, means translating the features of the
spec into test cases -- code. When you port a language from
one platform to another, you can usually use the documentation
of the original implementation as a guide, too. The Processing.js
team had the benefit that the original implementation also
came with a large set of test cases. This allowed them to
write code against tests from the beginning, and then write
their own tests before writing code that went beyond the scope
of the original.
The next time I teach our compiler course, I hope to do a
better job getting students to write tests sooner, if not first,
as a matter of habit. Perhaps I will seed the teams with a few
tests to help them get started.
~~~~
The passage above comes from
the chapter on Processing.js
in Volume 2 of
The Architecture of Open Source Applications.
This was a good read that taught me a bit about Javascript,
HTML 5, and the web browser as a platform. But most of all
it explained the thought process that went into porting a
powerful Java package to an architecture with considerably
different strengths and weakness. Language theory is all
fine and good, but language implementors have to make
pragmatic choices in the service of users. It's essential
to remember that, in the end, what matters is that the
compiler or interpreter produce correct results -- and not,
in the case of a port, that the resulting code resemble the
original (another lesson the Processing.js team learned).
Another lesson this chapter teaches is to acknowledge when
when program doesn't meet everyone's expectations. This
was a serious challenge for Processing.js, because Java
makes possible behaviors that a web browser does not. When
you can't make something work the way people expect, tell
them. Processing.js provides documentation for people
who come to it with a Processing background, and documentation
for people who come to it with a JavaScript background.
Next up on my reading list from AOSA:
the design of LLVM.
-----