Open frahugo opened 3 years ago
I think the problem with extra parameters is that you'd need some way to know which commands do or don't have extra parameters, and how to supply them. You could modify the library to always take an extra argument for options, allowing you to call it by filling that parameter in for testing.
My motto for testing commands would be to try and isolate the necessary logic outside of the command itself, which would act as glue for the most part. So you'd be able to test the parsing function in isolation, the logic for choosing what text to return etc.
This requires a bit more work, but is a bit plainer to understand. For integration, it makes more sense IMO to test how these things interact with the actual API, since most problems will be around things like not calling the right effectful function, or things like that.
Thanks @cronokirby. Yes, the service will definitely be tested out in isolation. It is in fact in a different child app in the umbrella. Here, I just wanted to make sure that I have some tests that covers the glue between Alchemy and my service, to have some peace of mind when in the future I upgrade elixir, alchemy or other parts of the code base.
Hi. I'd like to be able to test my cogs using
mix test
. I looked atViviani
but did not find any tests for the Cogs.I basically want to make sure a Cog properly performs its job and if I set a custom parser for a command, the right arguments are sent to the function. I would also like a way to inject mocks. Either by adding that to the
message
variable available in the Cog, or preferably passing options to the command function (seehello
below).It could look like this:
Is there anything I can do for now for testing my Cogs without having the source code of Alchemy changed?