Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test framework #28

Merged
merged 5 commits into from
Sep 20, 2024
Merged

Test framework #28

merged 5 commits into from
Sep 20, 2024

Conversation

mike-sul
Copy link
Collaborator

No description provided.

@mike-sul mike-sul force-pushed the test-framework branch 3 times, most recently from bfb433b to 347f29a Compare September 12, 2024 10:30
@mike-sul mike-sul marked this pull request as ready for review September 16, 2024 13:12
@mike-sul
Copy link
Collaborator Author

@doanac @detsch This PR includes all I planned to add to the "test framework" during this initial implementation iteration.

Copy link
Member

@doanac doanac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be easier to introduce the test fixture utilities at the first and then do the test files. It would make the PR a little easier to focus on what you are testing

c.Dir = appDir
output, err := c.CombinedOutput()
if err != nil {
t.Errorf("failed to run `%s` command: %s\n", args[0], output)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably want t.Fatal here or your test is just going to fail everything after this. It's also going to get tedious checking for errors everywhere. The require.Nil package/function makes this a lot easier

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get the feeling all your tests are going to need this function. I'm guessing the code is going to be easier if you make this a function

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me restructure the PR so the fixtures appear at first and then the test cases. Probably, after that the comments will become irrelevant.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The require.Nil package/function makes this a lot easier

Agree, the simple function should do the trick, not sure it is worth pulling another deps for it though.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@doanac I've restructured commits in the PR. Please, review it now.

test/fixtures/images/runner/forever.go Outdated Show resolved Hide resolved
test/fixtures/composectl_cmds.go Show resolved Hide resolved
@mike-sul
Copy link
Collaborator Author

I think it would be easier to introduce the test fixture utilities at the first and then do the test files.

I suppose it makes sense from the test case perspective, and a commit history will be cleaner. I will update PR accordingly. (I just wanted to justify the fixtures and how they evolutionary appears)

@mike-sul mike-sul force-pushed the test-framework branch 2 times, most recently from a8fd8e5 to c786354 Compare September 18, 2024 13:46
Copy link
Member

@doanac doanac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a lot easier to follow. thanks.

@@ -0,0 +1,31 @@
-----BEGIN CERTIFICATE-----
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might include the script to generate this. You have the conf file. I remember using something like this from moby once and losing 15 minutes needing to generate a cert.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a compose-based environment to build, run, and test the composectl
utility.
The environment includes the foundries specific docker registry
and daemon (vanilla version + required patches).

Signed-off-by: Mike Sul <[email protected]>
Add tests for the following cases:

1. The same image is used by more than one compose service.
2. There are more than one version of the same app in the app store.

Signed-off-by: Mike Sul <[email protected]>
@detsch
Copy link
Member

detsch commented Sep 19, 2024

Perhaps adding a comment to the README.md mentioning how to execute the e2e tests locally would be helpful, which seems to be:

./dev-shell.sh
make test-e2e

Other then that, LGTM.

@mike-sul
Copy link
Collaborator Author

Perhaps adding a comment to the README.md mentioning how to execute the e2e tests locally would be helpful, which seems to be:

./dev-shell.sh
make test-e2e

It makes sense, I'll update the readme.

@mike-sul
Copy link
Collaborator Author

@detsch 6eca275

@detsch
Copy link
Member

detsch commented Sep 20, 2024

@detsch 6eca275

Looks good

@mike-sul mike-sul merged commit f10453c into main Sep 20, 2024
2 checks passed
@mike-sul mike-sul deleted the test-framework branch September 20, 2024 14:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants