Skip to content
This repository has been archived by the owner on May 13, 2020. It is now read-only.

Automated tests #28

Open
SeanTAllen opened this issue Aug 6, 2017 · 8 comments
Open

Automated tests #28

SeanTAllen opened this issue Aug 6, 2017 · 8 comments

Comments

@SeanTAllen
Copy link
Member

At the moment, the best we can do when checking a PR is to verify that stable builds. We have no automated tests of basic functionality. I'm opening this issue to collect and track thoughts on what tests we should add.

@SeanTAllen
Copy link
Member Author

@jemc @Theodus any thoughts on what automated tests for stable would look like?

@jemc
Copy link
Member

jemc commented Sep 14, 2017

Maybe it could be an integration test that sets up an example bundle.json that clones its own repo (pony-stable), and imports some types to prove that it worked?

@SeanTAllen
Copy link
Member Author

@jemc i was just thinking the same thing. and then compile the program with stable env ponyc.

we can verify

  • bundle file is correct after the add (this could be expanded for each type eventually)
  • stable env ponyc compiles program

eventually i think we'd want to test other features like

  • tag
  • local-git
  • github
  • stable add

@SeanTAllen
Copy link
Member Author

@rawkode any interest in this one? it's a little more advanced but probably manageable as a start. there's a bit of "how much can we use ponytest for" (a lot see https://github.com/ponylang/changelog-tool/blob/master/tests/main.pony tests)? and some would have to be some kind of automated integration test(s), so there's a bit of complication but its pretty straightforward. if you are interested, i'd say drop idea here for tests and what the runner would be and @jemc and I could give feedback.

@rawkode
Copy link

rawkode commented Sep 17, 2017

@SeanTAllen Yeah, I'll look at what I can do and come back with a plan 👍

@SeanTAllen
Copy link
Member Author

@rawkode assume. i just sent you an invite to be part of our "contributor" team. it doesn't give you much in the way of privileges but does allow for you to appear in the "Assignee" list and be assigned to issues you are interested in working on. Baby steps towards committer!

@rawkode
Copy link

rawkode commented Oct 3, 2017

So this is pretty tough.

My initial thought is that we need a JSON Schema that will evolve with the tool and provide a means of documenting the format for other integrations; as well a confidence that stable conforms with said schema.

From what I can tell, we could probably use ponytest for arbitary comparison tests, but it wouldn't be pretty and we'd need to provide the json for comparison. Which means, in order for the test not to be flaky, we need to add branching/tag/commit sha support to stable add

assert_eq("json", loaded_bundle.json)

Hopefully any assumptions I've made are correct 😄

srenatus added a commit to srenatus/pony-stable that referenced this issue Jun 14, 2018
The rationale for this new target is that for ponylang#28, we'd probably have
these tests depend on git being installed; and 'make test' should still
"just work" for everyone.

Also, this is differentiating test cases by their _names_, not labels.
This is because I haven't found a way to _exclude_ based on a label, to
have `make test` not run any of the integration tests. (Short of adding
label=unit to all the unit tests, which would of course be another
option.)

Signed-off-by: Stephan Renatus <[email protected]>
srenatus added a commit to srenatus/pony-stable that referenced this issue Jun 14, 2018
The rationale for this new target is that for ponylang#28, we'd probably have
these tests depend on git being installed; and 'make test' should still
"just work" for everyone.

Also, this is differentiating test cases by their _names_, not labels.
This is because I haven't found a way to _exclude_ based on a label, to
have `make test` not run any of the integration tests. (Short of adding
label=unit to all the unit tests, which would of course be another
option.)

Signed-off-by: Stephan Renatus <[email protected]>
srenatus added a commit to srenatus/pony-stable that referenced this issue Jun 17, 2018
The rationale for this new target is that for ponylang#28, we'd probably have
these tests depend on git being installed; and 'make test' should still
"just work" for everyone.

Also, this is differentiating test cases by their _names_, not labels.
This is because I haven't found a way to _exclude_ based on a label, to
have `make test` not run any of the integration tests. (Short of adding
label=unit to all the unit tests, which would of course be another
option.)

Signed-off-by: Stephan Renatus <[email protected]>
@srenatus
Copy link
Contributor

srenatus commented Jun 18, 2018

I'll try pushing this forward. #70 gets some scaffolding in place, leaving open the following test TODOs:

srenatus added a commit that referenced this issue Jun 18, 2018
…ersion` (#70)

Notably absent: setting up temp directories, doing any real changes
to the filesystem as part of the tests. This will be handled in follow-up
PRs.

Notes on this change:

* Add new make target 'integration', have 'test' exclude them

The rationale for this new target is that for #28, we'd probably have
these tests depend on git being installed; and 'make test' should still
"just work" for everyone.

Also, this is differentiating test cases by their _names_, not labels.
This is because I haven't found a way to _exclude_ based on a label, to
have `make test` not run any of the integration tests. (Short of adding
label=unit to all the unit tests, which would of course be another
option.)

* Test Usage output with different arguments to stable

I would also propose to exit with a non-zero exit code when we present
the help output because the arguments didn't match anything.

But currently, this accurately reflects the behaviour.

* Makefile: differentiate sources for $(binary) and $(test_binary)

It was a bit annoying to have

    make integration

rebuild `build/release/stable` when the only thing that had changed was
the (integration) tests.

Signed-off-by: Stephan Renatus <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants