Tracking: Refactor and clean up architecture

[CraftSpider]

• [ ] Things should have their own files
  • [x] FakeState
  • [ ] FakeHttp
  • [x] FakeWebsocket
  • [x] Callbacks
  • [ ] Assertions
• [x] More assertion functions, fewer boolean flags
• [ ] Clarify: Backend vs Frontend state. One is 'discord', the other is 'us'
• [ ] Complete missing functionality

This list may be edited / have associated issues linked to it as changes are made

[bravosierra99]

Please let me know if there is some way I can assist or if there is something you would like me to work on.

[CraftSpider]

Some thoughts on 'more assertion functions': Given the gradual increase in flags, I think it may be worth it to go the way of libraries like junit or such, where you write asserts more like

runner.verify().message().text("foo").embed(embed).peek(True).assert()

runner.verify().nothing().assert()

runner.verify().embed(embed).no_text().assert()

This would be a bit of an undertaking, but would increase assert flexibility, improve readability, and decrease duplication. I don't really like every method having a ton of boolean flags on it, but having an exponential number of methods for all the options is also not a great solution, this solution takes a nice middle-ground.

[JayDwee]

As much as that would be quite cool, since this is meant to work with pytest, I'd probs recommend using similar stuff to them (which I believe it currently is, but don't quote me) rather than junior for java. Also saves a breaking change from being made we which is never ideal if avoidable 😁

[Sergeileduc]

Hi !

Yeah that would be great to decrease duplication, etc...

I know nothing about junit.

Maybe we could do this in pytest with some parametrized fixtures and parametrization stuff ? https://docs.pytest.org/en/6.2.x/parametrize.html#parametrize-basics https://docs.pytest.org/en/6.2.x/example/parametrize.html

(maybe there are plug-ins on PyPI too, to help writing the matrix of inputs / expected output, etc...)

[CraftSpider]

I opened a PR for my proposed change (#49). I believe the predicate/builder style is more in keeping with the pytest philosophy of explicit asserts, and that we will need to make a breaking change at some point to fix the current situation, so better to do it all at once then not have to again. I did look into fixtures and parameterization, but they really solve different classes of problem unfortunately. I would appreciate reviews, note that while the change is major on the backend, changing asserts was almost automatic (verify_message("FooBar") becomes verify().message().content("FooBar"), which I could have written a tool to change, and may do so if demand is high enough).