-
Notifications
You must be signed in to change notification settings - Fork 0
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
Test framework #28
Conversation
bfb433b
to
347f29a
Compare
There was a problem hiding this 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
test/integration/smoke_test.go
Outdated
c.Dir = appDir | ||
output, err := c.CombinedOutput() | ||
if err != nil { | ||
t.Errorf("failed to run `%s` command: %s\n", args[0], output) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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) |
a8fd8e5
to
c786354
Compare
There was a problem hiding this 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----- |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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]>
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]>
Signed-off-by: Mike Sul <[email protected]>
c786354
to
8bba07d
Compare
Perhaps adding a comment to the README.md mentioning how to execute the e2e tests locally would be helpful, which seems to be:
Other then that, LGTM. |
It makes sense, I'll update the readme. |
Signed-off-by: Mike Sul <[email protected]>
No description provided.