Using Jasmine 2.0?

[ghost]

Are there any reasons why you must use jasmine-node (or indirectly Jasmine 1.3) and cannot use Jasmine 2.0 directly? I ask because then we could merge the jasmine-unit and jasmine package efforts when both use the same Jasmine version. Jasmine 2.0 has support for node.js backed in. I have a working server branch: https://github.com/Sanjo/meteor-jasmine/tree/server-testing

My vision is to provide one Jasmine package that can do client and server testing with the same syntax. The user can choose to run the tests in a fully stubbed environment or partly stubbed environment.

[samhatoum]

I like both of those ideas.

No reason for jasmine 1.3 and jasmine-node has a 2.0 branch. If we can get reporting directly from direct jasmine2.0 + node then even better than to parse XML.

I'm happy to work on a unified jasmine testing package with you.

[samhatoum]

On a side note, I see both benefits and danger in doing in-context mocking.

Benefit is no stubbing required so quicker to get started.

Danger is no isolation and in Meteor land, there a lot of magic/convention which means behaviour and state can sneak in. Mocking only a part of an in-context Meteor instance would cripple that instance and its behaviour could become unstable in other areas the use may not be expecting. I would call this pseudo-unit testing :)

Don't get me wrong, I'm interested in the approach and nothing will beat a real test!

[ghost]

If we can get reporting directly from direct jasmine2.0 + node then even better than to parse XML.

I'v got it working in the branch. Here is the boot script for Jasmine. It currently runs directly in the Meteor app, but creating a separate process or context is also possible. The velocity reporter that I wrote for Jasmine communicates by calling Meteor methods, so the DDP npm package can be used too.

Another apporach for running the unit tests: I think the unit tests can run isolated in the Meteor app by using the node.js vm module. You can create a new context with a completly stubbed and therefore isolated global context. This approach does not require to mimic the file loading of Meteor.

[alanning]

I looked into the vm module a bit in the beginning but since we are using the jasmine-cli it didn't really buy us anything. Curious though, even if loading jasmine and using VM, wouldn't we still need to load the app files in the regular Meteor loading order? The app files themselves probably depend on that order being maintained.

You probably already know this but the way jasmine-unit works is similar to using a vm. The in-Meteor-context main file kicks off jasmine-cli in a child process and we just tell jasmine to load our files in lib first before the tests. The files in lib do stuff like stubbing and loading the app files in the proper order.

[ghost]

The idea is to run the tests in an app instance where everything is loaded already. My assumption is that everything that needs to be stubbed is in the global object or is required by the app with Meteor.require. So the auto stubber just has to stub the global object and then we can use vm.createContext(stubbedGlobal).

[samhatoum]

I'm for the running in-VM approach as it would run in the same server environment as meteor, which is a plus. and I think stubbedGlobal would work just the same as the way we do it now.

[ghost]

I have successfully implemented the test running with vm.createContext. It must still run in a (light) mirror because isolating the global context is very hard. There is no super reliable way to get an exact deep copy of any object (see http://stackoverflow.com/a/728694/759971). For the same reason resetting the global scope after each test is problematic. So my implementation just resets the stubs for now. That means that the user is responsible that no unit test calls code that has global side effects. We make that easier by providing auto stubbed packages and spyOn is also a great tool.

[samhatoum]

Yay!!!

What about simply discarding theVM and starting another one? That would reset the global scope

[ghost]

The objects that were created by the app code would still be shared. A reliable way would be to start a new meteor process for each test, but I guess that it too slow.

[samhatoum]

I don't get it! Can I look at some code when you have it ready?

[ghost]

The code is in the server-testing branch: https://github.com/Sanjo/meteor-jasmine/tree/server-testing I don't load the app code myself. Meteor loads it and I just use the objects that the code has created. So I need to copy those objects into the context that I create with vm.createContext.

An alternative is to use the file loader from jasmine-unit and create a new context for each test. That could work.

[samhatoum]

Yea, that's exactly how I was thinking about it. True isolation