cannot read property 'replace' of undefined

[tonymckendry]

I am attempting to write a client-side test that involves some database manipulation. I am able to run a db.find({}) command without problems, but when I try to interact with the db in any way (remove, insert etc) I get the error: "Cannot read property 'replace' of undefined". The Meteor Guide mentioned to use your package when testing the db on the client side, but so far it doesn't seem to be making a difference for me.

[hwillson]

Are you able to share some of your code showing how you're using this package? For a few small usage examples, check out the tests.

[tonymckendry]

Absolutely:

I have a collection call "SchedShifts" that I need to test - I need to remove everything in the collection before each test, and insert some data. In my beforeEach function, when the 'SchedShifts.remove({}) line runs, I get the "Cannot read property 'replace' of undefined" error.
I have tried stubbing the collection outside of the beforeEach function and some other places in the test, but so far have been unsuccessful

`

    beforeEach(function(){
        StubCollections.add([SchedShifts])
        StubCollections.stub()

        SchedShifts.remove({})
        SchedShifts.insert({data})
        console.log(SchedShifts.find({}).count())

});

`

[hwillson]

You should be able to remove the SchedShifts.remove({}) line; When you call StubCollections.stub() your SchedShifts.find({}).count() should be 0, before adding any data in (so no need to remove anything).

[tonymckendry]

While that is true, I have attempted this without the remove() as my DB should be empty when the tests run for the first time; regardless, without the remove() my count is still 0 after the insert and the insert causes the "cannot ready property 'replace' of undefined" error to appear in my browser console.

[jaskinn]

Could the aldeed:simple-schema package cause any issues? I just noticed your latest commit.

[tonymckendry]

@jaskinn unfortunately the code that i'm speaking about here is for a different application than the fantasy football project that i've been committing to on github. You bring up and interesting point, however, as the simple-schema package is more strictly used on the app in question. @hwillson - do you know of any conflicts?

[hwillson]

Hmm - I just accepted PR #9 which relates to simple-schema. I'm out of time today unfortunately, but I'll run some more thorough tests tomorrow morning. I just published version 1.0.2 with the latest simple-schema changes; maybe update and try that version out. Otherwise, I'll post back with more details tomorrow.

[tonymckendry]

Will do, I'll let you know how it goes! Thanks!

[hwillson]

@tonymckendry Looking at the following:

SchedShifts.insert({data})

Can you give me an example of what data looks like, along with your SchedShifts schema config?

[tonymckendry]

Certainly - I was just about to update and try the new version out

Data:

    SchedShifts.insert({
      start: faker.date.past(),
      finish: faker.date.recent(),
      company: {
        shiftId: faker.random.number(),
        unitId: 34,
        personId: 4,
        jobId: 2
      },
      state: {
        geo_confirmed: false,
        django_has_it: true,
        status: shStatus.delivered
      }
    })

Schema:
`

export const ShiftSchema = new SimpleSchema({
    start: {
        type: Date
    },
    finish: {
        type: Date
    },
    company: {
        type: companySchema
    },
    state: {
        type: StateSchema,
        optional: true
    }
});

let companySchema = new SimpleSchema({
    shiftId: {
        type: Number,
        label: "Shift Id",
        optional: true
    },
    unitId: {
        type: Number,
        label: "Unit Id"
    },
    jobId: {
        type: Number,
        label: "Job Id",
        optional: true
    },
    personId: {
        type: Number,
        label: "Person Id",
        optional: true
    }
});

let StateSchema = new SimpleSchema({
    geo_confirmed: {
        type: Boolean,
        label: "The user was confirmed as being at the unit",
        defaultValue: false
    },
    django_has_it: {
        type: Boolean,
        label: "Is this shift stored on django",
        defaultValue: false
    },
    status: {
      type: Number,
      label: "Status of the shift state",
      defaultValue: 2
    },
    group_time: {
      type: Boolean,
      label: "Shift was generated in group time mode",
      defaultValue: false,
      optional: true
    }
});

`

[tonymckendry]

@hwillson - with the updated package, no difference. Same error

[hwillson]

Thanks @tonymckendry - arg, caught in meetings; I'll get back to this shortly. I'll put together a small repro mirroring your data/schema, and see what I can find out. More details shortly.

[tonymckendry]

@hwillson No worries, you're the man for helping me out and being so responsive

[hwillson]

Hi @tonymckendry - I've wired up a small attempted repro here, using your example schema and data. Everything seems to work properly, so I could be missing something. Take a look and let me know.

[tonymckendry]

Sorry @hwillson I havent gotten a chance to review this yet, but am really going to try tomorrow. Havent forgotten about you

[JosieMcClellan]

Hi @tonymckendry, just confirming that you're using the stock Mongo.Collection class and not a custom subclass. StubCollections uses this code:
new collection.constructor(null, options)

I'll change my own subclass to work better with the standard (name, [options]) signature.

[tonymckendry]

Sorry for the delay, I started looking at this again today and began by changing over to the practicalmeteor:mocha package rather than the dispatch:mocha-browser package to try to emulate exactly what you were doing in that example repo @hwillson -but my client tests seem to be running on the server side for some reason and I have yet to figure out why.

[thebarty]

Hi guys,

for me the simple-schema will NOT work, when using the transform-approach for collection-helpers, like:

CollectionSuper = class CollectionSuper {
  constructor(doc) {
    _.extend(this, doc)
  }
  // CollectionHelpers are placed here
}

TheCollection = new Mongo.Collection('thecollection', {
  transform(doc) {
    return new CollectionSuper(doc)
  },
})
TheCollection.attachSchema(TheSchema);

Is there any workaround? I'd love to avoid changing the whole collection-helper-approach in a large project to be able to use this. ?

[francis-lookback]

@tonymckendry Have you tried upgrading to v1.0.6?

I encountered the same error and it turns out it was masking an issue with the meteor sinon package that stub-collections used in v1.0.3. The issue is from an old version of sinonjs: sinonjs/sinon#710