Actually, this is not the real test I am having trouble with. I just adapted the example from the guide to something that I thought was equivalent. I have gotten a similar test to work.
The one I haven’t gotten to work relies on a callback that takes longer to trigger than .focus() (i.e. there’s a network request involved). My guess about why it won’t work is that the withRenderedTemplate() helper uses the callback in a synchronous manner, and does ends up removing the rendered view before the callback returns.
I guess I’ll just have to try and rewrite that helper to support asynchronous callbacks as well…
I have a Blaze component and I’m testing it as described in this article, using the withRenderedTemplate helper.
Let’s say I want to write a test for a method I’ve attached to the template instance (in Template.name.onCreated). I can’t for the life of me figure out how to get hold of the Template instance that was rendered.
As it is, the helper calls the callback only with the DOM element that the template was rendered into, but not the instance. I’ve spent an hour reading the docs and trying different things, but I can’t seem to get the template instance from either the el or Blaze.renderWithData.
Hi guys, I feel like I am incredibly late to the party here so sorry for raising this from the depths but…
I am unable to work out how to set a Reactive Var in a Mocha Unit test for Blaze.
Use case:
I want to test that my “Edit” and “Delete” buttons are appearing when I click an “Edit My Cases” button (button#editAllCases), which uses a Reactive Var to determine the state.
Setting the data parameter of withRenderedTemplate as the Reactive Var name (I didn’t think this would work but got to the point of trying anything
it('click Edit it can delete entries', function () {
let data = {
editModeCases: () => true,
};
withRenderedTemplate('Cases', data, el => {
expect($(el).context.innerText).to.include("Exit Edit Mode")
expect($(el).context.innerText).to.include("Edit")
expect($(el).context.innerHTML).to.include("Delete")
});
});
NB: The actual functionality works, its just the test that I can’t figure out…
Happy to provide further code / repo if it helps, but thought it might be unnecessary at this point…
I think this kind of test case is kind of hard to write in general, and is why I think you see a movement (esp in React) to separate presentation from state (see “stateless functional components” in React and the “withState” recompose higher order component).
So if you were following that movement you’d split your “stateful” CasesWithState from Cases (which took editMode and onSetEditMode as arguments), and write your tests against Cases.
A simpler approach is just to synthetically click the edit button in your test case.
There’s not really a good way to actually mess directly with the ReactiveVar, unless you write your code to allow it, which seems a bit of a bad idea.
In that case, I will write a Chimp test as a workaround for now to provide coverage, though that is a resource heavy way of testing such simple functionality.
Very interested about what you wrote regarding separating presentation and state - will look further into this. React is on my (long!) list of things to learn.
I am having problems getting mocha to work with XML on CirclCi. It seems like practicalmeteor/mocha and dispatch:mocha are both having problems genererating XML files.
One notable example is the practicalmeteor:mocha package. If you have been using this test-driver package, we strongly recommend switching to meteortesting:mocha instead.
Another option (might be easier) is to use the cult of coder meteor mocha version. The previous meteor/mocha integration broke due to the update of coffee script.
What are people using for acceptance tests? Chimp/Chimpy (which is what appears on Meteor’s test docs…) appear to be dead projects now unfortunately. Thanks.
To teach my students how to do it, I provide a sample system (BowFolios) with TestCafe tests that are integrated into a CI pipeline using GitHub Actions.