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
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
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
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. 
1 Like
- 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
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
Wow thanks for the feedback everyone, apparently there’s a need for a few screencasts 
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
[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
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
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 
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
I think that you are very easy to follow, and I like your programming style a good amount
1 Like
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
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
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…
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!
I run all my Mocha client tests with Velocity (mike:mocha) . MDG will use practicalmeteor:mocha.
1 Like
Ah, gotcha. Velocity is using Karma under the hood for client mode. I’ll checkout practicalmeteor:mocha soon.
1 Like
Sounds great, I can’t wait! Do you have an ETA? 
1 Like
Hoping to record the first part tonight or tomorrow and the 2nd part right after Christmas (it seems like the beta is stable enough to migrate now). Soon
1 Like
This is only true for package testing btw, for app testing, I’m not sure exactly how they’re going to do it yet.
Dou you mean module unit testing? With 1.3 I hope I can unit-test using modules instead of packages…