unit test question

[Trung Pham]

which unit test framework do you recommend to test socketstream server side code?

is socketstream built to support unit test? like mocking the request/response objects.

thanks.

[Owen B]

Hi Trung

Personally I like mocha: http://visionmedia.github.com/mocha/

I've not yet decided what's the 'best' way to test SocketStream apps but it's something I want to look at soon. I do have a few random thoughts on this:

1. Any business logic should live in separate modules which are independent to SocketStream (I wrote about this idea a few weeks back here: https://groups.google.com/forum/?fromgroups#!topic/socketstream/Z5z2YWY2Tag )

2. It would be possible to create a new interface for the RPC handler which helps with mocking on the server-side

3. Potentially we could also create a new transport just for internal testing (bypassing Socket.IO entirely)

4. I would like us to explore the possibility of testing your app using a UI in the web browser. There are so many advantages to doing this, including a graphical representation of the test coverage.

Thoughts by all welcome.

Owen

[Davis Ford]

Hi Owen,

I just re-read your post on isolating b-logic in the /app folder -- seems to make sense, and I intend to go down that path.  That said, are there any other simple examples out there for interested dev's to look at?  I'm still in the process of finalizing which frameworks / components I'm going to use, and still working out how best to structure/organize the app.  Example apps in socketstream are still pretty sparse, and I know the documentation is something you intend to work on.  

On a related note - a lot of the examples that do exist are done in coffeescript.  I chose not to do my app in coffeescript.  I'm sure I'd have no problem picking it up, but eventually other people are going to join this codebase, and I'd rather not have yet another thing for them to learn.  I'm still not officially sold on its benefits...point being, it makes the examples that do exist a little more difficult to navigate.

I guess what I'm driving at is that a straightforward js socketstream example built in a "recommended" way might go a long way in helping early adopters.

Regards,

Davis

[Owen B]

Hi Davis

I totally agree. Not a day goes by when I don't wish for the time to create example/demo apps, but right now all my focus is going into releasing 0.3.0 later this month. Once that's done my attention can turn to example apps, more documentation and improving/marketing www.socketstream.org.

I agree most (if not all) example apps should be in Javascript rather than CoffeeScript.

If anyone is interested in contributing an example app to be featured on our website, please let me know and I will assist in anyway I can. I'm particularly interested in working with designers as all our example apps need to look visually stunning, as well as demonstrate elegant code and best practices.

Owen

[Mathieu Civel]

I'm quite happy with the way socketstream allow my project to be browser tested.

I use mocha and expect.js (works in ie6) with the following dir architecture :

code/

  app/

    moduleA/

        file.coffee

        tests.coffee

    moduleB/

        tests.coffee

  lib/

     common/

     tests/

        mocha.js

        expect.js

  tests/

     entry.coffee

in app.js :

if (ss.env == 'development') {

  ss.client.define('tests', {

    view: 'tests.jade',

    css:  ['libs', 'mocha.css'],

    code: ['libs/common', 'libs/tests', 'app', 'tests'],

    tmpl: '*'

  });

}

in tests/entry.coffee :

mocha.setup 'bdd'

$ ->

    require '/moduleA/tests'

    require '/moduleB/tests'

I personally preferred to keep my tests in module directories but it should be easy to move them is /tests (Ultimately I also would like to have templates and css files in theses modules, like in BEM architecture).

Pros :

- Live reload works if tests or code is updated. It's nice to see tests passing as the code is written.

- Possibility to tweek tests/entry.js in order to load tests based on URI ( localhost:3000/tests/moduleA )