-
Notifications
You must be signed in to change notification settings - Fork 141
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
add validate_test.go to do unit test #188
Conversation
On Tue, Aug 09, 2016 at 04:17:40AM -0700, 梁辰晔 (Liang Chenye) wrote:
You probably want to add a Makefile and/or .travis.yml entry to run |
for _, c := range cases { | ||
spec.Version = c.v | ||
msg := checkSemVer(spec, "", false) | ||
if len(msg) != c.expected { |
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.
Is “number of error messages” really what we want to be checking here? I'd rather have a bunch of potential version strings with true/false for whether we thought they were valid, and error if we thought a version was valid and checkSemVer
gave us error messages at all (logging the error messages with t.Fatalf
) or if we thought a version was invalid and checkSemVer
did not give us error messages.
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 are right, it is not necessary to check the number of error messages.
On Tue, Aug 09, 2016 at 04:17:40AM -0700, 梁辰晔 (Liang Chenye) wrote:
While I'm in favor of Go tests for our implementation, I'm not sure We'll also want a way to distinguish between “that's not valid” errors |
I think it is a good idea to move 'validate' to a new directory like 'generate', I'll make a patch to move that. (just back from a long time leaving) |
expected bool | ||
}{ | ||
{rspec.Version, true}, | ||
{"0.0.1", false}, |
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.
0.0.1 looks like valid SemVer to me. What's the error message?
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.
Currently only support rspec.Version.
if version != rspec.Version {
msgs = append(msgs, fmt.Sprintf("internal error: validate currently only handles version %s, but the supplied configuration targets %s", rspec.Version, version))
}
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.
On Mon, Sep 05, 2016 at 03:38:57AM -0700, David Liang wrote:
{"0.0.1", false},
Currently only support rspec.Version.
So maybe leave a comment on this line that we're confirming a
shortcoming of the current test suite with this entry.
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.
Thanks, I added a 'FIXME' to mention this.
type Validator struct { | ||
spec rspec.Spec | ||
rootfs string | ||
hostSpecific bool |
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'd rather make these properties public, and Generator.HostSpecific
is public. Do you have any reason to keep any of them private?
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.
Do we need to see and modify these? I think the 'Check*' functions are enough.
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.
On Wed, Sep 07, 2016 at 09:04:44PM -0700, 梁辰晔 (Liang Chenye) wrote:
+type Validator struct {
- spec rspec.Spec
- rootfs string
- hostSpecific bool
Do we need to see and modify these? I think the 'Check*' functions
are enough.
Making them public means you don't need getters/setters and you can
still support users who want to partially setup the instance when they
call NewValidator (or whatever 1) and finish the setup later. Or if
they want to peer inside to get more details on why their validation
is failing. Or who knows? I'd rather err on the side of “we're all
consenting adults” 2, because I don't see a way to make validation
go terribly wrong if a user gets or sets one of these values whenever
they like.
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.
Hi @wking , I modified codes according to your suggestion. |
return Validator{}, fmt.Errorf("Cannot find the root path %q", rootfsPath) | ||
} else if !fi.IsDir() { | ||
return Validator{}, fmt.Errorf("The root path %q is not a directory.", rootfsPath) | ||
} |
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 “does the rootfs exist” check should be a separate check in Validator.CheckAll()
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.
done in new commit!
8d5cb3a
to
a8c02cf
Compare
return Validator{spec: spec, bundlePath: bundlePath, HostSpecific: hostSpecific} | ||
} | ||
|
||
func NewValidatorFromPath(bundlePath string, hostSpecific bool) (Validator, error) { |
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 these NewValidator*
functions should return (*Validator, error)
.
a8c02cf looks good enough to me (I think we've agreed to punt on
everything I'd still like to change).
|
Travis fails because of: |
#7cd3aa1 rebased on top of current 'master'. @Mashimiao @mrunalp PTAL |
so the test fail is due to go1.5? |
@vbatts yes, I'll rebuild the CI.
|
Signed-off-by: liang chenye <[email protected]>
@mrunalp @Mashimiao rebased. It is a code struct change, please PTAL first :) |
|
LGTM |
Only add a test case on checkSemVer in this PR.
Signed-off-by: liang chenye [email protected]