About Unit Testing

twitter logo github logo ・1 min read

Hello Developers!

I'm just getting started to writing a Unit Test, okay this is too late, but better than never.

So, I have some confusion on writing unit test. Let's say I create function that sum two given number:

  function sum (num1, num2) {
    return num1 + num2

And the test is:

describe('add', () => {
  it('should add two numbers', () => {
    expect(sum(1, 2)).toBe(3)

If I pass string to my sum function, it's absolutely fail. To make another test, should I return "error" and give a message that we should pass number to parameter not string, or instead we parse it to number if the parameter is not number?

Thanks 😃

twitter logo DISCUSS (10)
markdown guide

What do you want the function to do if you pass it a string? Test for that.

Behavior in edge cases like this is extremely dependent on context. You should test that the code behaves how you expect it to, but your expectations are up to you.


Hey, Thanks for reply.

I need a feedback from you, if you write that simple sum function, do you prefer to give a message that this function only accept number parameter (if we pass string to parameter), or parse it to number instead (so we shouldn't create unit test for the parameter is must number)?


That's your call. What it "should" do depends on how you mean to use it. If you want it to throw given a string, write a test to ensure that it throws when you pass it a string. If you want it to parse strings, write a test to ensure it parses valid strings and another test to validate what happens if you pass it 'abc'.

And for what it's worth, sometimes it's easier to think about this stuff in advance of having written the function itself—that's the big draw for test-driven-development. Think through the functionality of the system through writing the tests as oppose to the other way around.

I tend to write tests for the expected cases and for the "unexpected but reasonably predictable ones". The rest is bugs or regressions :D

As Dian said a function that sums to number could raise an exception if one of the operands is not a number or could cast it as a number and do the sum or return NaN. The right answer depends on your context @filosofikode


In my opinion, you should return "error" and give a message that we should pass number to parameter not string.
You said it yourself - "If I pass string to my sum function, it's absolutely fail."
If someone used your function in the wrong way - they should know about it!
Which framework do you use for unit testing?


Thanks for your opinion! This is what I need. I'm using Jest btw.


Great :)
Do you program in languages other than js?


I think the question is not how you reponse in the test, the thing is what you want to do in your func? And what it does to handle edge cases ( raise error or give warning etc) then test are just to verify. Hope this help


Would suggest that writing automated unit tests for that level of processing is really a waste of time. I refer to that kind of testing as the 'homeopathic unit testing antipattern'.

Classic DEV Post from Oct 31 '19

What Alternative Text Editors Does DEV Use? (Not VS Code 🐱‍👓)

Fariz profile image

Night owl? 🦉

dev.to now has a dark version (in public beta).

Go to the "misc" section of your settings and select night theme ❤️