executing manual testcases

@raff, I saw your modification. I’ll try to understand if we can definitely get rid of that method from UI test library.

About test redundancy, I already noticed it, indeed I’ve worked on AddEditBlockTest (or something like) ManageProviderScheduleTest and DeleteBlockTest, sorry I don’t remember the exact names and I can’t check them. Anyway, I’ve already proposed to merge some of them, but there is a tradeoff as you make me notice a post ago. We have to deal with the size of the test itself. Therefore, in my case I’ve kept the original classes, but: a) aggregate common behavior in the Manage … .java b) Differentiate the behavior of Add… and Delete… in a way that if Delete fail for sure you know that it is not due to the edit of existing appointment. if only Add fail is likely due to the edit operation because Delete should fail as well. Despite my effort to separate the behavior they still have some similar actions.

You can look at my pull request. Said that, I’ll look at the classes you mentioned above and discuss with you or whoever interested in possible solutions. Maybe, I can do this:

  • examine all the test cases
  • identify which overlaps
  • discuss with a strategy to apply to all test cases (and eventually to document if it turns to be successful)

Thank you.