Testing guide article

Thanks for the response @tmeasday.

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…

1 Like

And publish it as a package? Would love to remove that custom code from Todos!

@tmeasday great idea! My first thought when I saw the helper in this article was “why isn’t there a package with some premade helpers for this?”

1 Like

@tmeasday Maybe you can help me with this:

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.

What am I missing here?

const view = Blaze.renderWithData(...);
const templateInstance = view.templateInstance();

@Sanjo I tried that. I’m getting TypeError: view.templateInstance is not a function.

I’m using Meteor v1.3.3.

Hmm, probably the result of renderWithData is the data view rather than the template.

Maybe you could try something like:

const parentView = View.With(data, function() {});
const templateView = Blaze.render(template, ..., parentView);

You might have to play around with it (and there’s probably a better way to do it!)

Probably a good thing to include in the helper lib :wink:

Is it possible to use “mocha --grep” in meteor test cli? It is so useful for TDD

@tmeasday

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.

Relevant View Code:

[....]

Template.Cases.onCreated(function() {
  this.editModeCases = new ReactiveVar(false);
  Meteor.subscribe('cases');
});

Template.Cases.events({
  'click #editAllCases, click #cancelEditMode'(event, template) {
    event.preventDefault();

    template.editModeCases.set(!template.editModeCases.get());
  },

[...]

Expected behaviour:

I can set the Reactive Var directly in my mocha unit test to test the Blaze View.

Actual behaviour:

No clear way to set Reactive Vars so they are recognised by the withRenderedTemplate function.

Attempted solutions:

  1. Putting this in a before clause
describe('Cases', function() {
  before(function() {
    resetDatabase();

    Template.Cases.onCreated(function() {
      this.editModeCases = new ReactiveVar(false);
    });
  });
[...]
  1. 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 :frowning:
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.

Thanks for the rapid reply.

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.

Hi guys,

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.

Does anyone have a solution?

Here are the details as an extra topic HOW to run mocha unit-tests on CircleCi and output XML?.

Do you have configure Karma using Meteor + Angular2 with typescript, I have some issues trying to configure it,any help!!!

This guide is obsolete, doesn’t work for Meteor 1.6.1 anymore, would be nice to update it to use meteortesting:mocha instead of practicalmeteor:mocha.

  1. Meteor 1.6.1 - Practical Mocha invalid reporter "[object Object]"
  2. https://github.com/meteor/meteor/blob/devel/History.md#v161-2018-01-19
 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.

@alawi thanks, but don’t have any change document.
Ex: package name to install…

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.

I’m using Cypress with a setup similar to the one described here https://marmelab.com/blog/2019/02/28/cypress-on-meteor.html

1 Like

I use TestCafe

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.

Some explanatory videos are here.

Philip

1 Like

What are people using for Unit tests in 2022? :slight_smile:

1 Like