You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of the problem is that some of the tests appear to expect a non-clean server, so the full tag list might be unknown, so the tags test doesn't really seem to assert a precise test list.
I recommend that we just drop this philosophy, and instead focus on testing in a clean test environment always, with a controlled tag list.
My initial motivation for this is to help keep a demoserver data limited. But I don't want to cron delete things, I'd rather "delete if there are too many and a new one is added" basis.
Implementing it in SQL properly also requires LOCKing which would serve as a valuable example.
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
The text was updated successfully, but these errors were encountered:
I chose to rely on a cron for the current API demo as I was urged to move forward to fix the NSFW situation.
To add LOCKing is entirely part of the changes I plan for the v2: both for the demo and the specs.
I'm not satisfied by the current API specs as there aren't guidelines about the database schema expectations, regardless of how to generate it.
Relevant Scope
Backend specs
Description
Currently there are no test that tags without any articles should be removed I think, but that is visible on
/api/tags
.The nicer behavior would be to delete the tags when they are not needed anymore to not clutter the server.
I would just add a test for that under
realworld/api/Conduit.postman_collection.json
Line 1864 in 78c4efa
realworld/api/Conduit.postman_collection.json
Line 2188 in 78c4efa
Part of the problem is that some of the tests appear to expect a non-clean server, so the full tag list might be unknown, so the tags test doesn't really seem to assert a precise test list.
I recommend that we just drop this philosophy, and instead focus on testing in a clean test environment always, with a controlled tag list.
My initial motivation for this is to help keep a demoserver data limited. But I don't want to cron delete things, I'd rather "delete if there are too many and a new one is added" basis.
Implementing it in SQL properly also requires LOCKing which would serve as a valuable example.
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
The text was updated successfully, but these errors were encountered: