Skip to content
This repository was archived by the owner on May 8, 2025. It is now read-only.
This repository was archived by the owner on May 8, 2025. It is now read-only.

Evaluate whether we can use a standard testing framework for integration tests #51

@lehnerpat

Description

@lehnerpat

I know your PR isn't really the problem here, but maybe we should think about extracting this logging logic into a util function, since it is copied in almost every error case in each integration test 🤔 I can imagine something like this

function logStdoutFailure(actual: string, expected: string)

would reduce code duplication in this project. Maybe it would even be a good idea to extract line 78 to 88 entirely ^^

Originally posted by @lieberlois in #49 (comment)

on the one hand, I agree we shouldn't let the duplication here increase too much.
on the other hand, I'd also prefer not to build our own testing framework from scratch :D

I think with the exit code handling in #48 and the still-to-do "suppressNotices" option (that I explained here: #47 (comment)), we should re-evaluate whether we could use a regular testing framework (like Jest) for our integration tests instead.

Originally posted by @lehnerpat in #49 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions