Conversation
7000db0 to
84802ca
Compare
There was a problem hiding this comment.
Honestly I'm not sure this is a good idea. This will add a 1-2 minutes to the test execution time for something that we haven't modified in a while. Thoughts on alternatives are to add the test, but not run it by default, but manually instead. Or we could test the schedule creation and confirm the entries are created in the database, even though that will not actually test execution.
What do you think? I'm all for adding more tests, that is definitely the right direction, but at the same time we need to keep the change-test-loop short. We can also start to see whether test execution can be parallelized, the different aspects should be largely independent of each other, that would also alleviate this issue.
84802ca to
4e7043c
Compare
|
Thanks for raising this, yeah, I've also have started to observe the test duration has increased. So I've removed this file from testpaths so that the test can be run manually if needed in future. Because Back schedule are an important functionality that we provide. It's better to have some form of automatic testing. It doesn't need to be tested for each PR. So removed this file from testpaths |
create a backup schedule and verify its backup (PVC snapshot) get created on schedule.