As a developer, a test app exists for working with things that aren't appropriate for platform.
In particular, this is needed to test Detail model types, but it would be generally useful to have a test app that demonstrates (and tests) the correct functioning of what platform provides to the plugins.
This test app should have Detail models type for the existing Master model types (Content, Importer, Publisher), as well as serializers and viewsets for each of those types.
Bonus points will be awarded for writing some useful tests of the Master/Detail relationship.
#1 Updated by semyers over 3 years ago
This is pretty focused on master/detail right now, but I suspect that we'll want to expand the acceptance criteria from here to include some other things that I may have left out here that are essential goals for a test app.
I thought I posted this on Friday, but apparently not. :(
#2 Updated by semyers over 3 years ago
I dabbled with the code side of this a little bit to see how loading the test app might work. Here's what I came up with as a sort of PoC:
#3 Updated by bmbouter over 3 years ago
That code looks good. How should we deliver this code to developers for testing? One way would be to make this the file plugin. Having this code used for more than just testing will likely keep it maintained and usable. If we don't plan to keep this around for a long time then just having it on a branch that we can grab from time to time would be fine too.
#4 Updated by semyers over 3 years ago
That code looks good. How should we deliver this code to developers for testing?
I was thinking pretty much as-is, embedded in the pulp.app.tests namespace. There's not enough functionality here to really help any developer out, though.
One way would be to make this the file plugin.
If that's the case, we should kill this story and do the ones about creating the file plugin. I don't think that's what this story is about, though.
Having this code used for more than just testing will likely keep it maintained and usable.
I think that having this code used solely for testing will have the same result. The point (as I see it, at least) isn't that the code is usable so much as the code is testable, and is usable as an example. I think we need a way to make sure the Master/Detail stuff is working as intended from Model to API ViewSet without using any single plugin to verify its functionality. This story (again, as I see it) is about providing that ability to validate critical platform functionality without doing it through a plugin (like we do now mostly with pulp_rpm and smash runs).
In the conversations about what to test and what not to test, I think we absolutely must test that our custom stuff (Master/Detail Models and related API objects, GenericKeyValueStore and related API objects, other custom model/manager behaviors, etc) works with every commit.
If we don't plan to keep this around for a long time then just having it on a branch that we can grab from time to time would be fine too.
I'd like to keep this around forever.
Please register to edit this issue