-
-
Notifications
You must be signed in to change notification settings - Fork 18
Automated tests #28
Comments
Maybe it could be an integration test that sets up an example |
@jemc i was just thinking the same thing. and then compile the program with we can verify
eventually i think we'd want to test other features like
|
@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. |
@SeanTAllen Yeah, I'll look at what I can do and come back with a plan 👍 |
@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! |
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 assert_eq("json", loaded_bundle.json) Hopefully any assumptions I've made are correct 😄 |
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]>
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]>
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]>
I'll try pushing this forward. #70 gets some scaffolding in place, leaving open the following test TODOs:
|
…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]>
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.
The text was updated successfully, but these errors were encountered: