Cleanup and test of garden connection configs #5
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Testing
This PR accomplishes two main goals:
to_brewtils
now correctly processes systems associated with a garden via an update tomake_object
ofGardenSchema
ingarden_schema.py
. The unit test intest/db/schema/garden_schema_test.py
demonstrates this.The functions that manipulate gardens in
garden.py
now call a functionclean_garden_connection_params
at points where the garden is inserted or retrieved from the database. This function only cleans up the garden connection parameters and passes the rest of the garden through untouched.This addresses the problem where a user upgrades to code that includes the garden schema but the database in the existing system may have gardens where the connection parameters are squirrely (and would therefore fail validation).
There are comprehensive units tests to cover all of the possible permutations of connection parameters, explained further below.
The unit tests for the connection parameters fall along three main lines: the
garden.connection_type
is one ofLOCAL
,HTTP
orSTOMP
. The tests thus verify each of the following cases is handled correctly:LOCAL
a. no connection params
b. connection params that are not empty
HTTP
a. good http, empty stomp
b. good http, no stomp
c. good http, bad stomp
d. bad http, no stomp
e. bad http, good stomp
f. bad http, bad stomp
g. no http, no stomp
h. no http, good stomp
i. no http, bad stomp
STOMP
a. empty http, good stomp
b. no http, good stomp
c. bad http, good stomp
d. no http, no stomp
e. no http, bad stomp
f. good http, bad stomp
g. bad http, bad stomp
The unit tests are tedious and repetitive (it would have taken too long to refactor them to make them simple and elegant for no real benefit), but they should cover all the combination of connection types and connection parameters.