What is TDDBin?
TDDBin had been started to provide a no-setup environment for the first JSCodeRetreat. Not everybody has jasmine, mocha or some other (unit) testing tool running locally and for a code retreat this is something that makes it much easier to get started. That’s where TDDBin came into play, I wanted one URL where you can edit and run unit tests.
That’s how TDDBin came about and now it has been relaunched, rewritten and open-sourced.
What is new?
The repo has moved. The frontend code, which has been open source for a while but never had been deployed has moved from uxebu’s github to github.com/tddbin/tddbin-frontend. Why the move? Some online tools want to have access to all your github user’s repos and since tddbin also serves as a playground I didn’t feel comfortable always giving access to all uxebu repos. That’s why I created the github user tddbin.
We use trello for ideas, feature voting, commenting, brain storming and everything before code gets written. If you have an idea for tddbin or miss a feature, please add a comment here. If want to vote for a feature please do so by clicking on the card (you need a trello account for that). Or if you want a feature really bad encourage others to vote for it (use the “Share and more…” link on a trello card to link to it) or create a pull request.
Keyboard shortcuts also work on non-Mac computers. The old version only used to work with the Mac’s Command ⌘ key, now also Control as used on other systems works. (I have seen it on Linux.)
No login required anymore. In the former version we stored the source code on the server, so you could come back and use it. This feature is gone but therefore also a github account is not needed anymore to use tddbin, so you can really start right away. The link tddbin.com takes you right to the editor and test runner, I hope this reduces the hurdle to use it and try it out even more.
The nasty trailing empty line bug is gone too :). I remember running around at our code retreats telling people to not forget a trailing empty line at the end of the file because there was a bug that will screw your code. This one is gone now. Back in the old version the loading process was very difficult and it was a monkey-patched requirejs in order to be able to load the code from localstorage. Fortunately this is gone and with it also the above described bug.
Firefox works too. Actually this is painful to admit but before Firefox didn’t work and I never got around to fix it. Now it does and I am glad I don’t have to carry that shame any longer :).
Currently tddbin is pure client side, once the site is loaded there is no more server interaction. Is this a feature or not – decide for yourself. That’s just how it is right now. Why? Basically in order to get out this version as fast as possible. And it still took sooo long. True.
Travis does the build. Travis does not only run the test suite, it also does the building and deployment. Currently this is done in the “after_success” clause of the .travis.yml. I want to deploy only after success, that is right. But if kicking off the build separately is right I am not sure, I remember reading travis docs which say it is part of what travis does. Feel free to improve it.
From travis it gets automatically deployed to github-pages. This one is really cool, imho. I had been tired of projects that are pure client side and hosted on github pages but I had to build locally and push to the gh-pages branch. This just felt so un-automated and a waste of my time (or: not lean as @borillo would say). Finally I scraped all the pieces together and made it work the way I think it is right. A project named push2gh-pages that provides this separately and reuseable as a npm module is under way.
The more the pain grew of having the source code just laying on github and not running in production, the less important the features became. Sure, no production, no real improvements are made and felt. So some features just didn’t survive.
Currently there is no jasmine support (this must change soon). It was just painful to hook up jasmine to report the test result using it’s API. Since that reporting feature actually is not even needed now, since there is no state to be stored in any backend it should be very simple to enable jasmine again. Which would require tddbin to get a switch for which test runner to use. Mmmmh, any good ideas?
The test and the source code you write is not stored on a server anymore. The sessions are not stored, as you probably already read above. Depending on how fast tddbin moves along this might change again.
Have fun TDDing away and if you care, feel free to help out by voting, commenting, opening issues, tweeting, blogging, etc. If you want to meet people and practice more often, check if there is a JSCodeRetreat somewhere near you, or make it happen.