feat: add testing utilities

[cschmatzler]

Adds testing utilities to Noora in debug builds that record output and allow us to do snapshot testing.
The output follows the format of

stderr: ▌ ✖ Error 
stderr: ▌ Error 
stderr: ▌
stderr: ▌ Sorry this didn’t work. Here’s what to try next: 
stderr: ▌  ▸ Consider creating an issue using the following link: https://github.com/tuist/tuist/issues/new/choose

[pepicrft]

@fortmarek we ended up going for subclassing here because we only wanted to extend the parent with some convenient API for testing, and dependency-inject a pipeline that would record the output. Let us know what you think of the architecture and if you'd do things differently.

[fortmarek]

Instead of subclassing, I'd lean to using a protocol and then using the real implementation under-the-hood:

public struct NooraMock: Noorable {
    private let noora: Noorable
    public init(theme: Theme = .default, terminal: Terminaling = Terminal()) {
        self.noora = Noora(theme: theme, terminal: terminal)
    }

       func yesOrNoChoicePrompt(
        title: TerminalText?,
        question: TerminalText
    ) -> Bool {
      noora.yesOrNoChoicePrompt(...)
   }
}

It does mean the mock needs to define all Noorable methods but I think that's an ok trade-off.

[cschmatzler]

I've applied this, I think. Would appreciate some comments on implementation details - will add documentation once the actual structure is signed off by you guys.

[fortmarek]

Aligned 👍

[fortmarek]

Overall, very much onboard with this 🙂

Since the NooraMock is something consumers of this library will use, I would add:

• some documentation for how to use the mock to the docs
• some tests that use NooraMock to snapshot test the output.

[fortmarek]

Instead of subclassing, I'd lean to using a protocol and then using the real implementation under-the-hood:

public struct NooraMock: Noorable {
    private let noora: Noorable
    public init(theme: Theme = .default, terminal: Terminaling = Terminal()) {
        self.noora = Noora(theme: theme, terminal: terminal)
    }

       func yesOrNoChoicePrompt(
        title: TerminalText?,
        question: TerminalText
    ) -> Bool {
      noora.yesOrNoChoicePrompt(...)
   }
}

It does mean the mock needs to define all Noorable methods but I think that's an ok trade-off.

[fortmarek]

Given this is something we expect consumers of Noora to use to snapshot test the output, I'd add documentation along some usage guidance.

[fortmarek]

Do all of these types actually need to be public?

[cschmatzler]

Fixed

[fortmarek]

Is this what developer should be using for snapshot testing or rather the description? Having an example using this mock in action would help a bit with the review as it's not super obvious how this is supposed to be used.

Either way, this property should either be private or public, but I don't see why it would be internal.

[cschmatzler]

tuist/tuist@main...cs/noora-success-messages

Here's a branch with what Pedro and I imagined in regards to usage.

[fortmarek]

@cschmatzler I'm onboard with the current changes. We can merge this once we add some documentation, including an example 🙏

[fortmarek]

[pepicrft]

Solid work 👏🏼