Introduce RetrieveAPIAutoTestCase #482
Conversation
This introduces the first auto test case for the retrieve API. The implementor provides the actual object under test, and a tuple of (username, password, expected_error). The expected error is what that user should get from the API. If it's `None`, that means the request should be accepted. If the request is accepted, we then use the serializer to figure out what fields the object is going to have. Most of the time, it's pretty straightforward, but sometimes (like for decimal fields, or relational fields), we have to do some transformations. This will (hopefully) make it much easier to add test cases to the API. Or, at the very least, it'll allow us to clean up our fugly existing test cases. Task: #475
| from huxley.api.tests import RetrieveAPITestCase | ||
|
|
||
|
|
||
| class RetrieveAPIAutoTestCase(RetrieveAPITestCase): |
There was a problem hiding this comment.
As we add more AutoTestCases, do you think we will be able to reuse some of the functionality by making an AbstractAutoTest case or something along those lines?
There was a problem hiding this comment.
I hope so! I figure we'll take it one step at a time, and the requirements of the other AutoTestCases will shape what the abstract one will look like.
|
This is awesome! |
| (None, None, cls.NOT_AUTHENTICATED), | ||
| (test_object.advisor.username, 'test', None), | ||
| ('user1', 'user1', None), | ||
| ) |
There was a problem hiding this comment.
I don't have a better way to write this now, but this return statement is not very clear. Maybe switching over to a python dictionary would allow more clarity and readability. For right now I think a class comment would suffice so that devs trying to replicate can easily do so.
There was a problem hiding this comment.
Yeah, agreed that this is pretty terrible. Let's keep thinking on it and make improvements later.
|
This is a great start. As mentioned above I think readability will be important as we introduce more automation. IMO there needs to be a bit more abstraction added between the implemented test case and the factory. That decoupling can come after we get rid of the old tests though. LGTM |
This introduces the first auto test case for the retrieve API. The implementor provides the actual object under test, and a tuple of (username, password, expected_error). The expected error is what that user should get from the API. If it's
None, that means the request should be accepted.If the request is accepted, we then use the serializer to figure out what fields the object is going to have. Most of the time, it's pretty straightforward, but sometimes (like for decimal fields, or relational fields), we have to do some transformations.
This will (hopefully) make it much easier to add test cases to the API. Or, at the very least, it'll allow us to clean up our fugly existing test cases.
Task: #475