Centralised Mock Objects

This topic contains 5 replies, has 2 voices, and was last updated by  Don Jones 1 week, 1 day ago.

  • Author
    Posts
  • #98953

    Dave Brannan
    Participant

    Does anyone keep mock objects in central files and then dot source them into context blocks when required?

    I'm thinking specifically of SQL objects and being able to test changing the schema without having to update every single test file that uses the object(s).

  • #98956

    Don Jones
    Keymaster

    I've done so. Works well.

    • #98959

      Dave Brannan
      Participant

      Ok thanks Don. Was it a similar use case? Trying to think of other cases where this approach might produce more robust tests.

  • #98964

    Don Jones
    Keymaster

    It wasn't SQL, no. I've actually got a bunch of mocked WMI objects I cobbled together, some AD objects, and a couple of others. I do it whenever I need a similar-seeming object (e.g., specific properties, most times) I want to make sure my code is working with correctly. Sometimes, I'll just have the mock run the "real" command (if it's non-destructive, like a Get-), and the serialize/deserialize those objects to create "dead" objects with the same basic members.

  • #98970

    Dave Brannan
    Participant

    Ok makes sense. What I'm trying to avoid is having tests that always pass without the mock objects actually representing the real objects, for example when a DB schema gets updated. By having a single version of each mocked object in a central file, will be easier to update in one place and then see how all tests handle it.

    Seems more robust than having multiple versions of the mock objects anyway.

  • #98973

    Don Jones
    Keymaster

    I'd probably code the mock to (if possible) query the actual schema. Saves updating it. But otherwise, yeah. What you said.

You must be logged in to reply to this topic.