Testing Meteor with Chimp

[ashhimself]

Hey,

My meteor app has gotten quite large over the last year and breaking it has become pretty easy when I make changes. I am looking to implement some test scripts to ensure my app isn’t breaking before I deploy to galaxy.

From reading the forums it sounds like Chimp is the suggested product? Could anyone point me to a decent guide, sample scripts? The Meteor guide itself I believe was too high-level for a beginner like myself.

Thanks.

[eleventy]

I was in the same situation a few months ago, and got into testing with Chimp and Cucumber end-to-end. What really helped was the tutorial on their site, but it seems to be empty now for some reason. If I check Google’s Cached version, it’s still there, so maybe take a copy of it. It gets you started really quick. After that, it takes a while to pick up speed.

End-to-end or acceptance IMHO are the best way to get started with testing: It gives you a lot of reassurance that your site keeps on behaving the way it should, from a users perspective. ( Basic idea is to look at your site through the eyes of a user: if I click on this button, I should see this, and if I enter this text over there and click the save button, I should see that).

Cucumber is a bit weird at first. But with a few tricks, it becomes really fast to check a lot of possible user interaction. My tip: build a library of generic steps: When I click on "#my_id" or Then I should see an element "#id_of_a_div" with text "the text". These generic steps with variables( the stuff in quotes) can be used over and over again.

Testing this way only works well, if you seed your (test-)database with the same data over and over again, as described here. That way you know that if you navigate for example to /list, that your page should contain a list of exactly 5 items, and that the second item contains the text “My Second ListItem”

[ashhimself]

Thanks for the detailed run down mate and link to the cached article. I will run through that tonight.

Have you dealt with much testing which has to interact with the database? e.g if I click ‘x’ button it should create a record in the database and have x,y,z fields at a min for the application to function correctly.

My application is an iOS app so I still need to manually test it on mobile but at a starting point I want to ensure all my functions/methods are all working.

[eleventy]

Yep, try to use the db in your tests. I typically seed my testDB with a few records. These records are reset before each test using fixtures: special methodscalls that are only loaded during tests ( by naming your file something like todos.app-test.js, they get only loaded in testmode ).

In my tests, I try to add and modify records, and check the results the server returns. Something like:

Feature: Integriteit ManualPage

  As a user
    I want to look at the Integriteit Manual page

  Background:
    Given I am in Desktop-mode
      And I am logged out
      And the userDB is reset
      And the integriteit.manual DB is reset


  Scenario: Integriteit.manual modify for admin user
    When I am logged in as user "admin" with password "test12345"
      And I navigate to the "/integriteit" page
    Then there should be an "#paperIntegriteit" element
    When I click on the "Chapter" sideMenu
    Then there should be an "#ManualContainer" element
      And there should be an "#ToolbarModify" element

    When I click on "#toggleModify"
    Then there should be an "#inpTitle" element
      And there should be an "#inpContent" element
    When I enter the text "New Title " in input "#inpTitle"
      And I enter the text "New Content" in input "#inpContent"
      And I click on "#btnSave"
    Then I should see an ".toast-message" element which contains the text "Chapter saved"
      And I click the ".toast-close-button" button
    Then I should see an "#titel" element with text "New Title"
      And I should see an "#inhoud" element which contains the text "New content"

[ashhimself]

Thanks! I’m going to dive into this over the weekend and see how I get on!

[janka]

@eleventy

using fixtures

I would advise against using fixtures. They have a tendency to grow and end up being a pain to maintain as the app evolves.

I start my test on an empty database, and let the test use the app to generate content.

Acceptance and load testing

I think this covers your 3.: We use chimp with cucumber for e2e testing - and fixture generating. Each cucumber feature is depending on another feature by a special comment at the top of the file. This way, we create a tree of features. After each feature is run, we do a database dump (feature dump). Before each feature is run, we load the feature dump created by the feature it depends on. The top most feature depends on nothing, and starts running on an empty database. This way, our fixtu…

[warehouseman]

If you want to get some hints, clues and tricks I’ve been using Chimp very successfully in my Meteor Mantra Kickstarter

You can see typical output in a recent CircleCI log. Just open the 4th from last field, where it’s labelled ${CHIMP_CMD} .e2e_tests/chimp-config.js --ddp=http://localhost:3000 --path=.e2e_tests.

One trick I’ve found extraordinarily helpful has been to invent my own namespace HTML tag attributes for every artifact I might want to select in a feature. So for example, it’s trivial to find a “save item” button if it’s explicitly labelled like this. In the step_defs I just declare it and select it when needed.

[warehouseman]

A really powerful, but easy to miss capability is, server.call. At any point in a step_def you can call a Meteor server-side method.

So here I delete all color items with a single call at the start of the relevant step_defs. The rest of the feature reinstates the deleted records by acting as users supplying the data as they work through the use cases.