Commit graph

9 commits

Author SHA1 Message Date
Brian C. Lane
548c58ddda weldrcheck: Convert to go testing framework + testify/require
Convert weldrcheck to use the standard go testing framework along with
the github.com/stretchr/testify/require assert package.

This also removes the cmd/osbuild-weldr-tests and builds the test binary
directly from the weldrcheck package. This makes it easier to organize
the code instead of putting it all into a single main_test.go file.
2020-03-17 21:10:00 +01:00
Brian C. Lane
e3d1a34ab6 weldr: Fix blueprints/depsolve response
The response always returns a 200 with a JSON response. Any errors will
be in the errors list.
2020-03-12 01:55:45 +01:00
Brian C. Lane
e13ebd46ee weldr: Fix blueprints/info response for unknown blueprints
The response is different for JSON and TOML requests. If it is JSON it
will always return a 200, but any blueprints with errors will be in the
errors list.

If TOML has an error it will return an error 400 with the error in a
standard API error response with status set to false.
2020-03-12 01:55:45 +01:00
Brian C. Lane
2675eff4eb weldr: Add tests for empty and invalid blueprints 2020-03-12 01:55:45 +01:00
Brian C. Lane
36c19d756a weldrcheck: Add tests for blueprint errors
Add tests for things like posting invalid or empty blueprints,
non-existent blueprints, and commits.
2020-03-12 01:55:45 +01:00
Brian C. Lane
46c3bed153 client: Use http.Client instead of a string for the socket
This converts the client and weldrcheck functions to use http.Client for
connections instead of passing around the socket path and opening it for
each test.
2020-03-09 18:02:54 +01:00
Ondřej Budai
284e9b9e53 fix linter errors
#261 was created before the introduction of the linter, therefore it wasn't
approved by it. This commit fixes all the introduced linter violations.
2020-03-03 14:26:13 +01:00
Brian C. Lane
9dafb3337b Refactor error handling in the client code
client errors are now returned as an 'error', API errors as APIResponse.
2020-03-03 12:21:40 +01:00
Brian C. Lane
f298fed16d Add weldrcheck package to hold the integration tests
These tests build on the client functions to run integration tests on a
running API server.

It uses the reflect module to examine the methods attached to the
checkBlueprintsV0 struct and run the ones with names that start with
'Check', also checking the type signature of the functions and failing
the test if any of them don't match.

This will make it easier to add more checks without needing to add
boilerplate call/registration of the functions in the top level runner.
Just add the new function with the right name and signature and it will
be run when checkBlueprintsV0.Run() is called.

Checks for other API routes should be added to their own modules. There
will be some duplication of the Run function in each, but I think that
it will help keep things more manageable by separating them instead of
putting them all into a single giant Run() call.
2020-03-03 12:21:40 +01:00