Merge lp:~elopio/snappy/test_go_info into lp:~snappy-dev/snappy/snappy-moved-to-github
| Status: | Merged |
|---|---|
| Approved by: | Leo Arias on 2015-07-16 |
| Approved revision: | 587 |
| Merged at revision: | 586 |
| Proposed branch: | lp:~elopio/snappy/test_go_info |
| Merge into: | lp:~snappy-dev/snappy/snappy-moved-to-github |
| Prerequisite: | lp:~elopio/snappy/test_go_xkcd |
| Diff against target: |
184 lines (+113/-11) 4 files modified
_integration-tests/main.go (+27/-3) _integration-tests/tests/01_test_info (+0/-4) _integration-tests/tests/10_test_info_has_stuff (+0/-4) _integration-tests/tests/latest/info_test.go (+86/-0) |
| To merge this branch: | bzr merge lp:~elopio/snappy/test_go_info |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Federico Gimenez (community) | 2015-07-15 | Approve on 2015-07-15 | |
|
Review via email:
|
|||
Commit Message
Translated the info integration test to go.
| Leo Arias (elopio) wrote : | # |
As an alternative, I thought about reading the info from channel.ini in the testbed; but then the test will be self-fulfilling because snappy reads from that file to print the info. And it would be duplicated, as we have unit tests that check the attributes of the release.
So, what I want is to make sure that we are running the tests in the image that we specified in the host. As how to pass that info from the host to the test bed, there are plenty of options. Different file formats, env vars, with the --setup-command... I just copied what we did on the sanity suite.
I'll change the file location.
| Leo Arias (elopio) wrote : | # |
Please give it another review. I'm not sure about removing the data files, as they can serve to debug an execution. And on prepare target we make sure that the dirs are wiped out before running a new test.
I think that the files will be collected as part of the artifacts, so maybe it's ok to remove them. But I don't know, lets talk about it and later we can make a branch that removes all the generated stuff.
| Sergio Schvezov (sergiusens) wrote : | # |
Just a small proposal for an alternate way to validate the output.
| Federico Gimenez (fgimenez) wrote : | # |
Great, we can take care of the generated files in [1]
Cheers!
[1] https:/
| Sergio Schvezov (sergiusens) wrote : | # |
A side effect of using a scanner is that you can c.Check every line for formatting (useful in snappy list where we have formatting guidelines)
| Federico Gimenez (fgimenez) wrote : | # |
@Sergio it looks very nice, thanks a lot :)
We could replace pattern matching with it in places where regex feels a little cumbersome, perhaps write a checker with this logic inside? (I feel very pro-custom-checkers today :D)
| Leo Arias (elopio) wrote : | # |
<elopio> sergiusens: I like your proposal for map + Scan, but for the format compliance tests.
<elopio> what we are doing in the integration tests is closer to pattern matching: a user will ignore big chunks of text and care only about some lines. I find regexp and .* to express that nicely.
<elopio> We have a card for the format tests, where we will want to check every single line. I'll copy your comment in there.
<elopio> what do you think?
| Leo Arias (elopio) wrote : | # |
Back to work in progress because this will now conflict with the branch that splits main.
| Leo Arias (elopio) wrote : | # |
<sergiusens> elopio: it's fine; scanning is also good to see how long a specific message takes to get on screen; but is leagues away
| Federico Gimenez (fgimenez) wrote : | # |
infoSuite is passing but I get this in one of the remaining shell tests:
****** Running ./_integration-
Can not find 'docker[
ubuntu-core 2015-07-15 108 ubuntu
generic-amd64 2015-07-15 1.4 canonical '
ERROR
FAILED: ./_integration-
AFAIU this will be removed in one of the branches, right?
Thanks,
| Leo Arias (elopio) wrote : | # |
Thanks for the review, and yes, removed in here:
https:/
Should land anytime now.


Looks very good, great idea checking the actual release and channel. I'm not sure I like the way that info is passed to the tests, do we have any alternative?
In any case, that file should be put under the _integration- tests/data/ output directory IMO, and perhaps be cleaned up at the end of the execution (we should talk about reusing the AddCleanup in the files outside the tests too).
Otherwise +1