If any Deno dev/members are here, it would be really really nice to see mocking/spy support in the Deno test framework.
This is the major thing holding me back from using Deno more at the moment.
Not being able to mock out a class/function or spy on a particular call etc means that there are large parts of my code/particular situations that are not able to be tested easily without refactoring my entire codebase to use manual IoC and excessive-OO to hide things away under layers of interfaces etc. E.g. I cannot currently mock out `Deno.connect` (....? or can I?) so it is hard to test all sitautions there. Unfortunately this sort of thing (connecting to a remote system) is often quite critical and would benefit hugely from extensive testing.
It would be great to be able to create tests where calls to Deno.connect throw errors, or where it returns 0 bytes, or a special sequence of bytes and so on and so on to verify that my code works - this is the classic sort of `Spy` functionality seen and used extensively in Jasmine et al.
I know there are third-party solutions to this, but it would be nice to see this in the standard distribution.
What language runtime provides mocking/spy support? This seems excessively catered to IOC OO design, not the kind of thing a multi-paradigm language usually supports.
AFAIK deno ships with "test" as a sub command - having access to mock/spy seems reasonable in that context. It sort of follows from the "batteries included".
Just like deno bundles typescript - there is a reasonable expectation to track latest stable typescript features.
I believe they intentionally left it up to third party modules instead of baking in one way of doing it. I created a module called mock on their third party module registry that can be used for spying on and stubbing functions. Even with third party modules, you cannot mock Deno.connect directly because the Deno object is not extensible. If you'd like to spy on or stub connect, you could have Deno.connect passed in to your function as an argument that you can replace in tests with a spy wrapper around it or your mocked out version of it.
This is the major thing holding me back from using Deno more at the moment.
Not being able to mock out a class/function or spy on a particular call etc means that there are large parts of my code/particular situations that are not able to be tested easily without refactoring my entire codebase to use manual IoC and excessive-OO to hide things away under layers of interfaces etc. E.g. I cannot currently mock out `Deno.connect` (....? or can I?) so it is hard to test all sitautions there. Unfortunately this sort of thing (connecting to a remote system) is often quite critical and would benefit hugely from extensive testing.
It would be great to be able to create tests where calls to Deno.connect throw errors, or where it returns 0 bytes, or a special sequence of bytes and so on and so on to verify that my code works - this is the classic sort of `Spy` functionality seen and used extensively in Jasmine et al.
I know there are third-party solutions to this, but it would be nice to see this in the standard distribution.