Testing Without Mocks
jamesshore.com
Testing Without Mocks
1–10 of 51 posts
Re: Testing Without Mocks
#2> The factory should create a “Nulled” instance that disables all external communication, but behaves normally in every other respect....
>...For example, calling LoginClient.createNull().getUserInfo(...) should return a default response without actually talking to the third-party login service.
So... a mock.
Re: Testing Without Mocks
#3I get that in other software stacks you might want to avoid mocks and stubs due to friction, but in JavaScript what's the big deal? Mocks are easy– just do it.
Re: Testing Without Mocks
#4If you make all your code as pure function, then testing is easy.
First thing to do: Stop using class. Ask yourself first: Should i use a class here and there ?
Wait, i miss something here: Writing pure functions is hard ?
Re: Testing Without Mocks
#5If you make all your code as pure function, then testing is easy. First thing to do: Stop using class. Ask yourself first: Should i use a class here and there ? Wait, i miss something here: Writing pure functions is hard ?
Alright, so you get numbers from a json file in a ftp servers, you use scipy.newton to perform root finding on it, but needs the number of steps to be outputted as well (which newton() doesn't return), and you will save the result in a postgres table.
All this should be send to a task queue, triggered by a call to your REST API.
Good luck with purity.
Re: Testing Without Mocks
#6> The factory should create a “Nulled” instance that disables all external communication, but behaves normally in every other respect.... >...For example, calling LoginClient.createNull().getUserInfo(...) should return a default response without actually talking to the third-party login service. So... a mock.
Exactly. All those talks are always going to tell you the same things:
- limit side effects to your program boundaries
- abstract boundaries with utility functions
- mock program boundaries for integration tests in those utility functions
And then they pretend they didn't see the mock part.
Re: Testing Without Mocks
#7> The factory should create a “Nulled” instance that disables all external communication, but behaves normally in every other respect.... >...For example, calling LoginClient.createNull().getUserInfo(...) should return a default response without actually talking to the third-party login service. So... a mock.
No that’s not a mock that’s a stub. See this book from software engineers at Google, it talks about various test doubles: https://abseil.io/resources/swe-book/html/ch13.html
Re: Testing Without Mocks
#8If you make all your code as pure function, then testing is easy. First thing to do: Stop using class. Ask yourself first: Should i use a class here and there ? Wait, i miss something here: Writing pure functions is hard ?
What's your definition of "pure function". Apparently not "pure function" in the sense of "pure functional programming", because if that were so, your claim would just be wrong. Counterexample: "printToConsole: IO[null]": is a pure function but still not easy to test.
Re: Testing Without Mocks
#9If you make all your code as pure function, then testing is easy. First thing to do: Stop using class. Ask yourself first: Should i use a class here and there ? Wait, i miss something here: Writing pure functions is hard ?
Alright, so you get numbers from a json file in a ftp servers, you use scipy.newton to perform root finding on it, but needs the number of steps to be outputted as well (which newton() doesn't return), and you will save the result in a postgres table. All this should be send to a task queue, triggered by a call to your REST API. Good luck with purity.
You’re describing a bad API to begin with. Those are too many steps to test at once too.
Re: Testing Without Mocks
#10I get that in other software stacks you might want to avoid mocks and stubs due to friction, but in JavaScript what's the big deal? Mocks are easy– just do it.
Mocks and stubs provide lower test fidelity than the real thing. Also makes your tests more brittle as you need to update them whenever the real implementation changes.