Hi, I normally contract in MSBI, Oracle, .Net/.Net Core, focusing on a property platform at the moment. Have also been working hard on upgrading my limited company website too.
Hello Snir, thanks for this. I really appreciate this article. I have never taken unit testing in js seriously. I only look upon unit testing server side as being important when it is calculations based. However, UT is a vital part of web applications and worth considering.
My understanding of stubs versus mocks is simpler.
I see stubs as representing data objects, possibly settings, or data sources from somewhere else.
Mocks are, like you describe - behaviors. For example, write file. You don't want to actually write a file, but arrange the fake/mock so it can simulate having written a file. These can then be injected into a receiver/consumer where it just does its job.
Can i ask, and perhaps you are not a C# developer, you read about FakeItEasy? It is an interesting approach.
The main challenge I find with languages such as JavaScript and Python is they are dynamic languages potentially making these more of a theoretic exercise than statically typed languages.
Finally, i find Javascript completely exposes intellectual property to the end client, so if the server can do the effort without penalty, i prefer to keep business logic there.
None of this is meant to criticize and again, many thanks.
Thank you for the comment (:
Actually everything I described here still stands in any context, frontend as well as backend testings with nodejs.
Everything you say is right as well, mocks allow you the fake a behaviour of certain object, and to test the behavior in place. This is why it is recommended to just use mock on one object per test unit - this way you make sure you are testing just one behaviour and not looking at some irrelevant internals.
Regarding the JS and Python beingh dynamic languages - I think this is another, super interesting and dense, discussion. About the correctness of languages without static types and how you should test them differently than statically typed languages (if you should do it differently, at all).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hello Snir, thanks for this. I really appreciate this article. I have never taken unit testing in js seriously. I only look upon unit testing server side as being important when it is calculations based. However, UT is a vital part of web applications and worth considering.
My understanding of stubs versus mocks is simpler.
I see stubs as representing data objects, possibly settings, or data sources from somewhere else.
Mocks are, like you describe - behaviors. For example, write file. You don't want to actually write a file, but arrange the fake/mock so it can simulate having written a file. These can then be injected into a receiver/consumer where it just does its job.
Can i ask, and perhaps you are not a C# developer, you read about FakeItEasy? It is an interesting approach.
The main challenge I find with languages such as JavaScript and Python is they are dynamic languages potentially making these more of a theoretic exercise than statically typed languages.
Finally, i find Javascript completely exposes intellectual property to the end client, so if the server can do the effort without penalty, i prefer to keep business logic there.
None of this is meant to criticize and again, many thanks.
Thank you for the comment (:
Actually everything I described here still stands in any context, frontend as well as backend testings with nodejs.
Everything you say is right as well, mocks allow you the fake a behaviour of certain object, and to test the behavior in place. This is why it is recommended to just use mock on one object per test unit - this way you make sure you are testing just one behaviour and not looking at some irrelevant internals.
Regarding the JS and Python beingh dynamic languages - I think this is another, super interesting and dense, discussion. About the correctness of languages without static types and how you should test them differently than statically typed languages (if you should do it differently, at all).