Screencast on Migrating from Meteor 1.2 to 1.3 with Tests

announce
1

I’m planning on recording a screencast over the holiday week and I would like to show everyone one way to migrate a Meteor 1.x app to 1.3 modules (using the latest beta).
I would love to hear what you would like to see in the videos (or even if anyone would be interested?)

If a single video gets too long i’ll break it up into a multi-part set.

Here’s the current agenda:

  • Write end-to-end tests on the current app to prevent regressions in the upgrade
  • Migrate the open sourced React-ive Meteor project to 1.3
  • Write unit tests while migrating each module
  • Write a few integration tests to test key areas (i’ll focus more on the unit and end-to-end)
  • Convert basic React components to stateless components
  • Unit test React components

I’ll likely use Karma + Jasmine for clienside unit test and Mocha for serverside unit tests. Karma can’t run server code (easily) so it would require another Node test runner for Jasmine. This will give me an opportunity to show you both Mocha and Jasmine. You should probably choose one for both of your unit tests.

For acceptance testing i’ll be using either Chimp or another JS based tool like Nightwatch. I’m leaning towards Chimp as i’ve been using it daily now and i’m really enjoying the synchronous code (via fibers).

I won’t likely test the Blaze code in this project as Blaze is very unfriendly to unit test (and the Blaze that exists is fairly logic-less).

Is there anything else that you would like to see covered?

edit
To round out the video i’ll add integration tests in a 3rd part for those interested in testing the entire app (and not just migrating to 1.3). I’ve been wanting to try out Gagarin so i’ll most likely use that for integration tests (as long as it doesn’t conflict with 1.3).

32 Likes
2

I think a lot of people could benefit from this. I’m always learning something from your contributions and I’m particularly interested in gaining some insights into how you write your tests. 1+

2 Likes
3

I would also encourage you to make the screencasts, i’m interested in seeing how you use the chimp for acceptance testing

1 Like
4

Would be great if you’d cover most recent problems
This time is quite different from meteor 1.0, people creating themselves problems rather than experiencing Meteor’s easy going flow.

1 Like
5

I cannot wait for this. Thanks for putting this together!

FYI - In case it informs any decision making… @sashko mentioned another thread that Chimp would likely be the testing tool used in the Meteor guide for end-to-end testing.

1 Like
6

it would be cool to see a working way to do simple unit tests with meteor, without setting up a huge complex fragile testing framework that will shortly be obsolete.

2 Likes
7

Really interested in this, and testing as a whole. What about using modules and a functional programming approach to decouple as many aspects of your testing as possible? Showing how to share and reuse test logic between tests, testing solutions, etc. I think it makes sense both in terms of showcasing the meaningful differences between testing solutions like you mentioned, and with the current flux around Meteor testing, how to make tests that are more future-proof, adaptive, etc. It’s asking a lot, but seems it’s where you’re going anyway. :wink:

1 Like
8
  • Differences between React.createClass and ES6 classes (extends React.Component), how to migrate to classes
  • If it’s possible, how to do the migration incrementally (migrate one part of the app but leave the others intact)
  • Adding CI?
1 Like
9

This sounds like it will be great! I’m very much looking forward to the testing bits as I’ve really struggled with figuring out a good testing strategy with Meteor.

1 Like
10

Wow thanks for the feedback everyone, apparently there’s a need for a few screencasts :smiley: Since testing seems to be so well received i’ll also writeup a summary blog post for those who prefer text.

I could definitely go more ‘functional’ with Redux and get near 100% coverage of the non-meteor front-end. However, for this small of an app the sticker shock of the boilerplate might be a net-loss. The ‘Domains’ and ‘Actions’ that I have should help improve unit testing without flux though :smiley:


[quote="csiszi, post:8, topic:15134"] Differences between React.createClass and ES6 classes (extends React.Component), how to migrate to classes [/quote]

I started to use ES6 classes for React Components and I found that in general it’s not worth using yet. The React API wasn’t really made to fully use classes and everything feels bolted on. Using some stage 0 transforms (like decorators and static properties) helps but is cosmetic at the end of the day.

However, take this with a grain of salt. I’m biased as I really think JS classes in general are a joke. JS does OO very poorly compared to Java/C# or Smalltalk. The new ‘classes’ do make it quack more like a duck but are fundamentally flawed. Using ‘classes’ or constructors in JS feels like a barnacles that were left over from the Java vs JavaScript war.


A lot of the React UI can be replaced with [stateless components](https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html#stateless-functional-components) (which i'll cover as well). The parts that cannot will just use the `createClass` for now. If the app is using Redux you can get by with > 80% of these being stateless components and the remaining 'container' components use `createClass` to subscribe to data.

In the future when using a ‘functional style’ is more popular, FB will start rolling out a more functional style API. The future of React state-full components will not look like a class, but instead it will hide the implementation of the ‘component’ and will expose props, state, and context as function params. Any hooks that you need can be exported as a function. This will eventually replace Redux (as you can tell it’s inspired by it). e.g.


// Callbacks take props and state as their first arguments. To update state,
// they simply return the new version of the state.
function handleClick(props, state, event) {
  if (event.button === 1) {
    // Middle click resets state to zero, return state
    return { count: 0 };
  }
  // Callbacks to external components may be fired
  if (props.onClick)  props.onClick();

  return { count: state ? state.count + 1 : 0 };
}


export function Counter(props : P, state) {
  return (
    <div>
      Clicked {state.count} times
      <button onClick={this(handleClick)} style={{ width: props.width }} />
    </div>
  );
}

And if your component needs didMount you can just export a function in the module above:

export function componentDidMount(props, state) {
  console.log('mounted');
}

Note, this was snipped from their react-future repo.

4 Likes
11

For those of us not (yet) using React, it would be great if you could split the presentation into at least two screencasts:

(1) Unit testing the domain model without reference to the UI.
(2) React-specific UI testing (either unit or e2e or whatever).

This also provides a way for others to more easily create variants (i.e. “Here is a screencast that covers the same material as (2), except using Blaze”).

Really looking forward to this screencast whatever form it takes. Thanks for your efforts to educate the community.

4 Likes
12

@philipmjohnson

So far it’s looking like it will be 3 parts, mostly to separate the testing from the actual migration parts.

Part 1
setting up Chimp to do regression/end-to-end tests. This is UI and even Meteor independent so it’ll work with React and Blaze. Also setting up the unit test framework Karma. This is also useful for Blaze or React apps. The main point here is to make sure the code still works after we migrate (without manually checking throughout the migration)

Part 2
This is the meat of the series and will focus on taking one module at a time to migrate. If you’re proficient in testing you can just watch the first 10mins of this and be on your way :thumbsup:

It will migrate global ‘object namespace modules’ to ES6 modules. A lot will be regular JS and not React components (even a few Blaze templates). I decoupled the UI pretty well so there’s really not a lot to test but i’ll also unit-test a few React components and a Blaze helper in this part (though Blaze is very hard to unit test).

Part 3
This will go over basic integration testing with Gagarin in 1.3 and will basically just get you going. Essentially it will only cover the ‘models’ to ensure we’re those are working. Perhaps testing publications too if that’s not difficult but our e2e tests should cover that as well.

I’ll also likely remove the Blaze shell, Blaze dep. and use React in it’s place. I doubt this part will be done before the holidays but it just depends on how long the first two take.

8 Likes
13

I think that you are very easy to follow, and I like your programming style a good amount

1 Like
14

If I am right the “official” meteor way of unit-testing will be Mocha-based. Are you using Karma because your tests are written with Jasmine?

1 Like
15

Karma is just the runner that glues together running tests in Chrome, Safari, Firefox, mobile, etc… and then reports back to the terminal. It supports Jasmine, Mocha, Tape, and a few others.

If the guides will be using mocha only and that will be the ‘default’ then i’ll consider using just that. I’ll just have to look into Sinon a bit, I haven’t used that in years.

The only issue with Mocha is that it’s harder to setup than Jasmine as Jasmine has stubs, spies, basic mocking, and the expect syntax built in. With Mocha you need to download sinon and an assertion library like chai.js or should.js

Jasmine is a one stop shop and Mocha is more of an À la carte setup (which is surprising that MDG would choose this as it’s more difficult to get going).

Another reason for me to use Jasmine is that i’ve been using it for years and i’ll be able to record the screencast faster (without stumbling about with API differences and cutting those out).

At any rate both are very close to each other and just have minor syntax differences. If I do go with Jasmine for the client i’ll use Mocha on the server (less code) so you can choose which one you like and use it for both client and server (Jasmine has a Node CLI runner too).

I’d also love to hear other opinions on this as well!

3 Likes
16

I use Mocha but a Jasmine tutorial is not a big deal. I was just wondering if the Karma layer won’t add too much distance between the tutorial and the standard testing procedure…

17

Does Mocha have a way to run tests in the browser now? (I haven’t used it in a while) The last time I checked you would need to have an html file and then would manually import each file with a script tag. The main issue with the html runner is that you would have to manually add babel while in Karma it’s just a config line.

It’s unfortunate that testing in JS is so difficult!

18

I run all my Mocha client tests with Velocity (mike:mocha) . MDG will use practicalmeteor:mocha.

1 Like
19

Ah, gotcha. Velocity is using Karma under the hood for client mode. I’ll checkout practicalmeteor:mocha soon.

1 Like
20

Sounds great, I can’t wait! Do you have an ETA? :smile:

1 Like