Screencast on Migrating from Meteor 1.2 to 1.3 with Tests

SkinnyGeek1010 · December 22, 2015, 4:25pm

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

sam · December 22, 2015, 4:52pm

This is only true for package testing btw, for app testing, I’m not sure exactly how they’re going to do it yet.

laurentpayot · December 22, 2015, 4:55pm

Dou you mean module unit testing? With 1.3 I hope I can unit-test using modules instead of packages…

sam · December 23, 2015, 3:54am

I mean that practicalmeteor:mocha is a package testing solution only (as things currently stand). It does not work for app-testing. The new changes from the MDG will replace Velocity’s “mirrors” with an app-testing mode.

Once this app testing mode is ready, it will allow for tools like the current mike:mocha or sanjo:jasmine to be ported over from Velocity. I’m not sure if the MDG will actually do something here or not, that’s not too clear to me yet.

As for unit testing, with 1.3 modules you no longer need to load the entire Meteor context. There’s already an example to do that here:

energistic · December 24, 2015, 2:46am

So looking forward to this! I haven’t been doing any testing and need @SkinnyGeek1010 to whip me into shape.

Sanjo · December 24, 2015, 3:08am

Only the sanjo:jasmine client unit mode is using Karma. The client intergration mode of sanjo:jasmine and mike:mocha is using a hidden iframe that is injected into the app. In Ci mode it is using PhantomJS.

jitterbop · December 26, 2015, 3:38pm

Hello, Are you still working on this.

SkinnyGeek1010 · December 26, 2015, 4:15pm

Yep! I did a ‘first draft’ of the part-1 Thursday but ran into issues using the plain webdriver syntax. I’m going to re-record it today using a set of helpers i’ve made that really help out on the race conditions and ‘why isn’t this working’ moments.

For example, i’ll use: fillInput('First Name', 'Adam') instead of using 3 or 4 lines of webdriver code (using things like waitFor a selector).

I wanted to try and not use my opinionated helpers but the 15min video turned into an hour with a ton of work trying to edit out the bad parts. The lib will be uploaded here: https://github.com/AdamBrodzinski/capy-js

apendua · December 27, 2015, 9:45pm

You should definitely have a look at the set of UI helpers I developed along with Gagarin, e.g.

github.com

anticoders/gagarin/blob/master/tests/specs/helpersDOM.js

describe('Built in DOM helpers', function () {

  var server = meteor();
  var client = browser(server);

  it('should be able to use sendKeys', function () {
    return client
      .sendKeys('input[type=text]', 'abc')
      .expectValueToEqual('input[type=text]', 'abc');
  });

  it('should be able to use click', function () {
    return client
      .click('input[type=button]')
      .expectTextToContain('p', '1');
  });

  it('waitForDOM should return true when dom object has been added', function () {
    return client
      .click('#waitForDOM')

This file has been truncated. show original

awatson1978 · December 27, 2015, 9:56pm

The Gagarin UI helpers are very good. I’m torn between which would be the better path… extending them so they match the Nightwatch UI helpers; or figure out how to require and add the Nightwatch helpers into Gagarin.

apendua · December 27, 2015, 11:05pm

I am currently in an porcess of refactoring different parts of Gagarin. I hope that after that it will be much easier to integrate with other testing libraries. In particular, you should be able to easily exchange & hook new helpers in both ways.

SkinnyGeek1010 · January 5, 2016, 7:23pm

Just wanted to pop in and say I haven’t forgotten about this. I had a Node service start acting flakey and had to re-write it in my free time over the past couple weeks.

Being that 1.3 isn’t prod ready yet I wasn’t in too big of a hurry. Should be able to tackle this next week

rdewolff · January 14, 2016, 3:53pm

@SkinnyGeek1010 looking forward watching these!

SkinnyGeek1010 · January 14, 2016, 6:20pm

I promise i’m making these soon I think Meteor 1.3 has settled down for the most part… mainly now there are not globals. I also have to catch up on the changes so far… I think there are no longer globals? so migrating might be more of a pain that originally planned

These won’t happen until the first week of Feb at the earliest… have to leave on a business trip and won’t be back until then. I don’t see 1.3 coming out before then so we should be ok

csiszi · January 15, 2016, 12:23pm

Keep on rolling!

Do they have an ETA on 1.3 or you’re just guessing from the current beta?

SkinnyGeek1010 · January 15, 2016, 4:52pm

just guessing based on the beta github issues and no release candidate yet.

cstrat · January 27, 2016, 2:22am

I’m very keen to see what you come up with here @SkinnyGeek1010.

I’ve been working on an app in 1.2 with react and am a little concerned that I didn’t start with the 1.3 beta… not sure what will break when I update to 1.3. not sure how much I will need to change or what will be impacted by the upgrade.

Sanjo · January 27, 2016, 3:03am

Sashko said in the latest weekly podcast that Meteor 1.3 will be backwards compatible with Meteor 1.2. So you can upgrade without making any changes to your app code. After that you can migrate to ES2015 modules if you want. This is also something you can do piece by piece. So no worries.

SkinnyGeek1010 · January 27, 2016, 6:24am

@cstrat I recently upgraded from 1.1 to 1.3 beta4 and it was very painless. You don’t have to import any Meteor modules and all of your code should load up as is. You can leave globals as is and can migrate them as you have time.

I was able to convert the browserify.js file that exposed globals to the 1.3 NPM imports and then for the most part everything stays the same. I had to remove the react package and import react from NPM, and exposed that globally as well. (as well as add the meteor data package back in)

In the future (in my app) i’ll work on converting a file from global to imports as I work on it (and also can test it easier). There’s no real reason to stop everything and import one file at a time.

For the tutorial app it should be a 3 min fix to switch browserify to npm imports and a working app. The rest would be just making it as good as possible (imports, etc…).

At any rate very little will need to be changed. It’s more less a little re-wiring to migrate browserify.

lgandecki · January 28, 2016, 2:53pm

That’s interesting.
We’ve tried today to upgrade our app to 1.3-modules-beta.5 and when trying to run meteor we keep getting errors like:

ReferenceError: later is not defined

related to code that declares some global variables like:
later = function() { }

Any ideas whether this will eventually be backward compatible as well? We know this is not a good style but we have quite a bit of legacy code, and packages, that do declare variables like this…

Or should we prepare for a big rewrite to get rid of all globals?

Edited:

Ok, I played around with this a bit more and looks like there are more problems (I needed to install packages like jquery or moment through npm, third part libraries that we have in our client/thirdparty folder have problems like:
“Cannot set property ‘Chosen’ of undefined” on a line that looks like:

" this.Chosen = (function(_super) {"

And I suspect there will be many more fixes to do. This is a huge production app (thousands of users at a time) that we’ve started in late 2012 learning on the way, switching from spark to blaze, etc. there is obviously quite a bit of code that could use some refactoring, but it works

So, I’m guessing, “backward compabilitiy” in this case means, “backward compatible as long as you have a proper es2015 compatible code”?