Testing "script-level" code

Welcome Forums Pester Testing "script-level" code

This topic contains 6 replies, has 3 voices, and was last updated by

 
Participant
1 year ago.

  • Author
    Posts
  • #81298

    Participant
    Points: 0
    Rank: Member

    Hi,

    What is everyone's approach to testing a script (i.e. a self-contained ps1 that contains parameters, functions, and code)? Rather than a module that contains a function per file.

    Basically same as https://github.com/pester/Pester/issues/21

    Would you always refactor to a module, or extract a function definition out of the script file (to avoid dot-sourcing?)

    Dave.

  • #81311

    Participant
    Points: 0
    Rank: Member

    To answer my own question, I've found a post by Jakub with possible solutions.

    http://web.archive.org/web/20160112151907/http://jakubjares.com/blog/2015/01/10/test-powershell-scripts-end-to-end-with-pester/

    Not sure if Pester 4.0 has any other solutions?

  • #81478

    Participant
    Points: 22
    Rank: Member

    Unfortunately, there is no good way to do it. Pester loves functions and if your code is broken up into functions, it makes your code not only cleaner but easier to test.

    Before you spend too much time trying to get this to work I'd first look to see if you can split out that script into multiple functions and then write tests for those.

    • #81484

      Participant
      Points: 0
      Rank: Member

      I've gone with the UnderTest switch for now. Problem is it's not my code and I'm fine with recommending it gets re-factored, but hoped there might now be an easier way to extract a function (for example).

      Thanks for the reply Adam.

  • #83965

    Participant
    Points: -19
    Rank: Member

    Thanks for reminding me of that article, I think you could solve that problem by building the whole script from smaller files before publishing. That way, during development you can test it as usual, and then on build we could have file-based-mock function that either uses the real file, or injects it's own definition. That would allow you to create version of the whole file that would be disconnected from the real architecture. Maybe we could leverage AST for that somehow, or template file where we know where to inject our functions.

    The whole problem pretty much is that in real script our mocked functions get shadowed by functions defined by the script, so we need a way to inspect the functions your script defines, generate mocks for them (if any mocks are specified), injects the mocks in the file, and then run.

    I will prototype it in the evening. 🙂

  • #83996

    Participant
    Points: -19
    Rank: Member

    Here you go, splitting the file (on comments now, but that can be done without). Might be useful?

    The links don't render properly here, making them -pre-.

    https://github.com/nohwnd/script-tester/blob/master/README.md
    https://twitter.com/nohwnd/status/929473308353056769

    • #84055

      Participant
      Points: 0
      Rank: Member

      Excellent, thanks Jakub! I'll have a play and see how useful it is for the scenario I was testing.

The topic ‘Testing "script-level" code’ is closed to new replies.