Add e2e tests to check the CLI

[camilamacedo86]

Description

This PR proposes to add a structure for we start to add e2e tests to validate the CLI

[doanac]

The hard part is developing the e2e tests. If we aren't going to commit to adding actual tests, this is just going to be noise.

[camilamacedo86]

Hi @doanac,

The hard part is developing the e2e tests. If we aren't going to commit to adding actual tests, this is just going to be noise.

Appreciate your insight! 🎉 . IHMO the significant challenge lies in establishing the API and creating a factory for testing. Using prod is off the table. Ideally, we should deploy everything via GitHub actions, which seems unattainable to me.

So, why did I push this PR?

My thought was: If we run basic tests to check the build (https://github.com/foundriesio/fioctl/pull/275/files) and bin functionality (or alternatively, by testing one or two commands directly in GitHub actions against all supported matrix), then we can easily merge the auto PRs GitHub throws at us to update project deps—no overthinking needed! I understand that currently, we are a bit hesitant to merge any golang dep or image update because we aren’t truly sure if it will break the build without manual tests.

But I am totally fine with close this one!

[vkhoroz]

@camilamacedo86 I think what you proposed to do is the correct way in general.
But, we have a plenty of work to do.

So, adding e2e tests for Fioctl should be prioritized first, as it requires a decent effort.
It is not equal to adding one test for one command out of hundreds.

Thanks for understanding and closing this.