Testing environment

[matisojka]

I have been working on a issue related to the validations and I have realized that the corresponding testing file is really large and that lots of assertations are grouped together. This made testing separate, smaller issues very difficult, because of the verbosity of the tests and the lack of options to decide which tests should be run inside the file (well, commenting out the code was my solution...).

I think tests should be splitted up into smaller, logical units and there shouldn't normally be more than one expectation for a single test so that identifying the error is more focused, faster and easier.

Of course this doesn't need to be done all at once, but it should be an important topic because a nice testing environment makes people test more, and that's what we want, don't we? :smile:

[thehydroimpulse]

Although I haven't really checked out the testing suite of Tower, its quite common to have more than one assertion in a single test; though, there is an excess amount.

We could, if @viatropos wanted, make each test, and each test file small to make it a rad quicker st running specific tests. On Oct 19, 2012 10:13 AM, "Mateusz Sojka" notifications@github.com wrote:

I have been working on a issue related to the validations and I have realized that the corresponding testing file is really large and that lots of assertations are grouped together. This made testing separate, smaller issues very difficult, because of the verbosity of the tests and the lack of options to decide which tests should be run inside the file (well, commenting out the code was my solution...).

I think tests should be splitted up into smaller, logical units and there shouldn't normally be more than one expectation for a single test so that identifying the error is more focused, faster and easier.

Of course this doesn't need to be done all at once, but it should be an important topic because a nice testing environment makes people test more, and that's what we want, don't we? [image: :smile:]

— Reply to this email directly or view it on GitHubhttps://github.com/viatropos/tower/issues/340.

[matisojka]

You're right, you can have more assertions in a single test, but only if there is a logical unit that justifies it.

Back to the validation example, all validations are tested in one single file, which will probably grow over the time, so I think it is a good idea to start refactoring the test suit so that testing is more comfortable.

Still, I know it's not priority no. 1, but let's keep it in the backlog.

[thehydroimpulse]

I'm currently working on a inversion of control container and more specifically a service locator (#325) which will be used throughout tower once its tested and integrate. This will however, change how you test (it will make it extremely easy because of mocking and faking objects).

So when this goes into tower , we can split everything into smaller parts. On Oct 19, 2012 11:01 AM, "Mateusz Sojka" notifications@github.com wrote:

You're right, you can have more assertions in a single test, but only if there is a logical unit that justifies it.

Back to the validation example, all validations are tested in one single file, which will probably grow over the time, so I think it is a good idea to start refactoring the test suit so that testing is more comfortable.

Still, I know it's not priority no. 1, but let's keep it in the backlog.

— Reply to this email directly or view it on GitHubhttps://github.com/viatropos/tower/issues/340#issuecomment-9608382.

[matisojka]

This sounds great, I'm still trying to get into this "brand new world" of Node.js, so I want to start small and do fixes here and there so I get a better feeling of the Tower framework as a whole.

[thehydroimpulse]

Yeah node.js is super complicated, especially with all this realtime stuff. But after a few weeks of ticketing around the source code and asking questions you should start to get the hang of things. On Oct 19, 2012 11:38 AM, "Mateusz Sojka" notifications@github.com wrote:

This sounds great, I'm still trying to get into this "brand new world" of Node.js, so I want to start small and do fixes here and there so I get a better feeling of the Tower framework as a whole.

— Reply to this email directly or view it on GitHubhttps://github.com/viatropos/tower/issues/340#issuecomment-9609522.

[lancejpollard]

Yeah there is a lot of room to improve the way tests are written in Tower's src, feel free to refactor it so it becomes more useable, I will definitely merge pull requests for this stuff.

A few notes. We should break up tests into as small of units as possible, but sometimes it's clearest/simpler to group a couple assertions into a single test (Rails' test suite has 2-3 assertions per test often).

Also, you can run single tests at a time by matching patterns in the test string:

mocha $(find test -name "*someTest.coffee") -g "some pattern"

That helps at times. But refactoring the tests so you don't have to comment out assertions while you're fixing something is a great idea, let me know if you have any questions.

[matisojka]

@viatropos thanks for the "pattern" tip, it sounds pretty good for now. @TheHydroImpulse commented he is working on some important internal changes that will affect the testing suite as well, so I'm looking forward to see it "in action".

[lancejpollard]

I've started porting the test suite to JavaScript:

https://github.com/viatropos/tower/blob/tests2js/test/cases/model/shared/attributesTest.js

Eventually the source code will be in JavaScript too.

The only thing left in that tests2js branch is creating the JavaScript API for the models/controllers, something like the stuff in this gist:

https://gist.github.com/8e78b21b37d21f43c495#file_test.js

Coming along! With pure JS we can sneak in many more optimizations. If anyone wants to help convert to JS (basically just copy the generated JS and clean it up a bit) feel free. Will take any-sized pull requests!

[thehydroimpulse]

@viatropos looks really good. I think coffee script and Ember made me love JavaScript even more. That api seems a lot more down to earth in a sense or low level. I also love having everything (or almost everything) an Ember object in some way.

I'll definitely take a wack at converting stuff to JavaScript. That'll let me experiment with Resolve.js (which got 100% on chromes speed test and profiler using JQuery, handlebars, emberjs, and a few views, templates and controllers)

[lancejpollard]

Didn't think that was possible to get 100% haha, nice! Yeah, I'm liking the Ember object / JS API better than the CS API, even though the CS API is "cleaner" (or more readable). It just feels more powerful.

I'm going to get the JS API for the model working on the tests2js branch, but I've also started on a src2js branch. Only converted one file so far (slightly modified the generated coffeescript file, will cleanup more):

https://github.com/viatropos/tower/blob/src2js/packages/tower/server.js

That src2js branch also has a better grunt file, which will copy any .js from packages to lib.