Screencast on Migrating from Meteor 1.2 to 1.3 with Tests

SkinnyGeek1010 · December 22, 2015, 4:07pm

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

csiszi · December 22, 2015, 4:17pm

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

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.