tddbin / tddbin-frontend

The source of TDDbin. -
http://tddbin.com
MIT License
225 stars 36 forks source link

Build Status Dependency Status devDependency Status Traffic stats Codacy Badge

TDDbin.com Frontend

Join the chat at https://gitter.im/tddbin/tddbin-frontend

This project contains all the UI stuff for TDDbin, it is runnable separately without any backend and aims to provide all components modularly. Please get involved on trello and vote or add ideas, comments, etc.. The highest ranked ideas will be the priority for us to implement.

Development

The short version using Nix (light-weight docker)

Run nix-shell -p nodejs-7_x and a nix-shell with Node.js installed will open. Now, continue in the next chapter.

The short version

In your shell:

The long version

In order to run this project locally make sure you have at least nodejs 0.10 installed

Now you can

and open the built version in the browser. Be sure to open the dist directory through a URL served by a local web server, such as an apache, nginx, etc.

Using the katas service

All pre-built katas are hosted in katas-service repo. Which gets deployed to http://katas.tddbin.com from where all the katas can be loaded and which can be updated independently, micro-service style :).

Do I need it?

If you want to work on the katas-service repo and want to load the katas into tddbin you might want to set up both repos to work with each other.
Other than that there is no real need to set up katas-service.

How to set it up

You don't need the katas-service to run locally, tddbin works also fully-functional without it.
If you also want to use the katas-service locally, clone the repo and make it available so that the env variable KATAS_SERVICE_URL points to where to find the proxy.html served by the built katas-service.

Coding style

The coding style is checked by running npm run lint using jsxcs a JSX-enabled fork of jscs. The applied style derives from the google coding style as contained also in jscs.

How to contribute

In order to contribute please provide a pull request, add a description to what your code does and how it is useful. It will be commented, discussed, maybe you need to adapt things and then it might be merged.

Test runners

The execution of tests takes place in a separate component, which can be hooked in where needed. This way adding a new test runner (e.g. qunit, tap, etc.) will be easy as long as it complies to the API that a test runner has to provide.

Jasmine Runner

It is in this repo, but is not finished. Due to jasmine's stubborn architecture that doesn't allow to reinstanciate it for a new test run as it would be needed for a single page app I just left it ... it's basically unusable :(. To try what it currently can do run the examples/test-runner/jasmine.html in your browser.

Mocha Runner

The mocha runner is integrated and will most probably become the default runner. For an example navigate in your browser to the examples/test-runner directory.

Assertion APIs

Mocha is assertion API agnostic, it brings it's own assert() function by default, that can be used. By adding plugins various other styles can be provided. See below which ones come with it.

Jasmine-style (currently not working, see code)

It is enhanced with referee, which provides jasmine-style expect methods. The tests can be written the same way as with jasmine (for the biggest part) - at least all standard matchers are available, for details see the docs.

Should-style

Also should-style assertions can be used. Thanks to Roman Liutikov pointing that out, it was added. On how to use them see the should.js documentation.

Custom runner

This architecture allows to add any kind of runner now. The easiest way for now is to duplicate the mocha runner and the example and get one up and file it as a pull request.