It was up in the air for a long time and finally I got around it to start open sourcing the code behind tddbin.com. After fiddling around with the existing code base I quickly arrived to the conclusion there is some major clean up, actually simplification and modularization very necessary. So I started to extract and change the frontend, which is the plan to be working standalone. It can be found on github.com/uxebu/tddbin-frontend.

The Master Plan

Actually I only wanted to finish the keyboard shortcuts that only worked on Mac OS X for now and they are actually very convenient when using TDDbin. Of course I wanted to test-drive the implementation and I did. It was more than a month ago, that I last touched the source code and I had to set it up on my new computer. This took me way too long and it was so tied up with the backend code, that I felt very quickly that this is not right.

So I separated out the frontend. And the plan is to have the frontend run separately since it is all just JavaScript, HTML and CSS. I want it all in a separate repo so it will be able for contributors to just clone the repo, do an `npm install` and off you can go. And using TDDbin without requiring a github account should come for free then.

The features this thing shall have:

• test-runner: The test-runner is the “view” that shows the test execution. It should be a standalone component, which can get source code pushed to it, that it then executes and shows the test results. By de-coupling this from the rest it will also be possible (for a contributor) to build a new test-runner for some other test framework.
• editor: This is the code editor, that is based on ACE and shall just have some small add-ons, such as the shortcut menu and provide hooks for retrieving, inserting, modifying the code, decoupled from ACE. This will also allow to replace the editor but which I think is way more important: implement features such as auto-completion, refactoring, etc. right into this component, instead of “somewhere in the project”. Again, focus is on maintainability and modularization.

I am sure there are more features that will come on the frontend side but for now this should be a good start.

Integrating Jasmine

The current online version of TDDbin has a jasmine runner, which I fought with some time in order to adapt and modify it so it does what I need it for the use case of TDDbin to do. Which is:

• allow to execute tests in a single page application and reinstanciate the runner with new source code
• provide statistics about the test run

It seems that jasmine is not really meant for those use cases. I had to hack into the boot.js to get out the statistics and I accepted that. But reloading the source code on the site was not so simple. The old version of TDDbin which is still online as of this writing uses lsjs which basically is a replacement for requirejs which stores all the files once loaded into localStorage. That made it relatively easy to update the test file and run it again. When I rewrote it as it is now in tddbin-frontend I felt that lsjs was quite some overhead, so I removed it and went without it. And that was a bit simpler. Though now I am passing the source code to the test-runner and eval it there pfui. I think this is not only ugly but also security-wise not so clever, since any code you write gets executed in the page context. I opened a ticket for it, if someone has a smarter idea I would be happy to accept a pull request for it or a hint.

Now that I had jasmine running without lsjs it always added the new test cases to the existing test suite and the number of tests did always increase. Digging into jasmine again … and I had done lots of it already. Man, if I could just get rid of this feeling that jasmine needs a rewrite :(. After half a wasted day I found out that I can simply get the top test suite and empty it’s children array, how ugly. I even asked on the jasmine list, see it also for the source code of how I did it.

Done. I thought. But as usual: the last bug fixed means that it wasn’t the last bug. Now I saw that the jasmine reporter, the HTML reporter in this case, that paints all the stuff into the site would also need it’s ass kicked and empty all the renderings it had done, so the results from a new test run would not show up mixed with the previous results. I searched for that for a bit but then I decided I don’t want a project full of hacks. So I dropped this approach. The jasmine test-runner is in the repo but it’s only half working :(. I give up.

Integrating Mocha

Now it was the right time to switch to something professional. I read a little bit on the web and also found in some blog post that “mocha can be configured to have jasmine-style expects”. And that is something I definitely want. I could not find it though. I think this post was wrong.

I would like the TDDbin users to write tests as fast as possible, no new assertion API, just use jasmine-style. And since mocha is assertion-style agnostic I thought this is a good use case to prove that. The TDDbin users should get the simplest assertion API possible and the quasi-standard is jasmine. So I want to have that. Fortunately I remembered that some uxebus have experience with that and David even uses it in many projects. He uses referee for that. As the referee docs say there is a jasmine-style assertion API. So I hooked that into the spec-runner.html which is the file that gets loaded into the iframe and fed with the test source code. No need to talk about the missing docs on how to use it with requirejs. (Gosh, I hate the package system mess in JavaScript. </rant>)
Alright, the assertion API is like jasmine. That is great.

Let’s try loading new test cases into the mocha environment. By default every doc says to use `mocha.run()` in order to run the tests. Of course the describe()s and it()s of our test source code have be run before and “registered” their tests with mocha. And as I expected too mocha would add every new test I try to run.
No problem I thought, mocha provides a class `Mocha` which I just instanciate and call run() on the new mocha instance. And of course this doesn’t work right from the start. In the end I searched in the mocha source code and found that the global mocha instance provided by the build is not a pure `new Mocha()` but a modified instance, which blew my entire hope of “switching to professional”. So I ended up with an alike hack for mocha test-runner as I had to do for jasmine. Though fixing the reporter was maybe simpler, since I knew which div mocha writes to, so I just emptied it’s innerHTML.

Fortunately getting the stats was a bit simpler, though not documented anywhere and I could only find out by diving into the source code. If you want to know how to get the results from a test run from mocha look into the source code here.

Finally

The mocha test-runner is working nicely, I am using that as default now. But integrating any of the test runners into a single page app didn’t make me happy at all. I guess that’s when one should take the time and contribute to a successful open source project. At least I started writing it down, who knows what else I will do.