I am currently learning to use Chimp for testing with Meteor. My current focus is on writing feature/acceptance tests.
How can I get Webdriver, in the context of using Chimp/Meteor, to wait for a previous step complete?
For example, let’s say I want to test a feature that requires a user to be signed in. Here, I would like to first reset the db, create an account, and then sign in the user, all before running the first test, which involves viewing a restricted page.
How can I do this?
Below is a pseudo code example to clarify more specifically what I am looking for. Any tips/advice would be highly appreciated. Yes, I know some of this might change with Meteor 1.3, but I’d rather try to figure this out now. Also, I have been using the Xolvio Best Practices repo as a reference, but I am not able to locate a solution for this there (or elsewhere.)
Example
Writing a test that requires a user to be signed in. The purpose of the before hook is to reset the db, create an account, and sign in the user, such that the first test can involve navigating to a restricted page.
this.Before(function() {
//Reset the db
server.execute(function () {
Package['xolvio:cleaner'].resetDatabase();
});
//create a user account
server.execute(function(user){
Accounts.createUser({
username: user.username,
email: user.email,
password: user.password
});
},user );
//HOW CAN I WAIT FOR THE ABOVE TO FINISH?
server.call('login', {
user: {username: user.username } ,
password:user.password
}, user);
//HOW CAN I WAIT FOR THE ABOVE TO FINISH?
};
//The actual tests, which would assume that a user is signed in...
All the server.execute / server.call calls are synchronous, and so is the code that runs inside the execute functions so you don’t need to wait at all.
It’s worth noting there are 2 contexts to login from, the server connection and the client or browser…
The server connection is what you use to do things like call and execute. The server connection supports authentication as you can see here: oortcloud/node-ddp-client.
I usually combined my logins so that I know any code I use in server.execute and client.execute is logged in. Here’s how:
This means I can just use fixtures.users.login({username: 'someone', password: 'letme1n'});
Note that the client.executeAsync method blocks in your test context until the done callback from within the client context is called.
Another gotcha to look out for is that you need to logout the server connection before killing the database, or the oortcloud/node-ddp-client will give you errors. So I have a single call to do resetting that looks like this:
fixtures.common = {
reset: function () {
// make sure the DDP connection is not logged in before clearing the database
server.call('logout');
server.execute(function () {
Package['xolvio:cleaner'].resetDatabase();
});
}
};
And now you can use fixtures.common.reset() in your before hooks. The client will automatically be logged out when the database is reset.
For some reason I missed the fact that the server calls as synchronous, which makes my main challenge somewhat moot. (Which is great!)
Also, I was not aware that there are two login contexts, and have been doing a server login only, which in fact may be the real reason why my initial test (that the user can access a restricted page) is failing.
I am trying to integrate this fixtures code with chimp tests within beforeEach and cannot seem to get it up and running … either fixtures is undefined despite putting your code as an object exported form fixtures or when do make amends the server is undefined within fixtures.
As a stop gap I now have a fixtures file in which the fixtures object is delcared and I import this at the head of the test specs.
Sundry annoyances I have with docs/examples is the interchangeable state between use of the variable/object name “client” or “browser”, which frequently breaks things, and then understanding that Meteor.* and Package.* calls need to be made within server.execute(function () { … and client/browser.execute(function () { … calls in order for these global vars to be available and to work.
I am looking forward to the update 1.3 meteor guide with testing detail, because a lot of what is available atm imho gives less chimp/selenium savvy devs like myself a bit of the run around.
No doubt things will improve and we will all get there in the end!
Support files under the support directory are loaded first by Cucumber-js. See here:
This is how the fixtures are available to steps.
Good point on the docs, I plan to revamp the whole triple-context experience by giving you warnings from within chimp when we can detect you’re trying to do something in a context that you shouldn’t be doing. I’ll also update the docs
Still super early days here but have been using chimp with mocha. Maybe I should switch to cucumber, as it might make more sense in terms of steps/.scenarios, rather than applying the same kind of logic that I do when using mocha in unit-testing.
I come from the dev end not the QA end of the spectrum of testing and old habits are hard to shake, building up technical debt when it comes to E2E style testing. Mainly trying to use the E2E to avoid headaches when testing multiple scenarios on complex form building app.
Don’t really want to start a whole mocha v cucumber debate, but at least Mocha is what I know and can write easily, without having to learn new method names that I already have to with WebDriver =)
PS. one annoying thing I found of late is that Meteor runs the chimp tests in my tests/chimp/ folder with *.spec.js file names rather than focusing on the *.tests.js files I have for unit tests. ACK!
Ah, I didn’t realize you’re using Mocha, the support loading first doesn’t apply there, though you can always rename the directory to _support and rely on FS loading order.
Good call on the .tests vs .specs - just added an issue for that. Will fix it soon
Left chimp on the backburner for now whilst I do more unit and other testing and coding.
Don’t really want to build up the technical debt and wasted hours when it is just me But I am super happy with the transition to Meteor 1.3 and testing abilities and simplicity certainly part of that!
