I don't understand unit testing, you won't explain it to me and I will never use it properly.

Go fuck yourself, internet of modules and node.js and fucktards who think they write good code but suddenly my simple webapp is 200mb big without even adding any content yet.

I agree that this test case example is egregious as it basically only tests the + operator of the language. With only one expectation.

For the sake of keeping this example:

Create a function sum accepting to parameters. Don't implement it.

Write a test case that you expect sum(1,1) equals two.

Now the test fails.

Make it pass by being a lazy / pragmatic developer:

sum = (x,y) => return 2;

Test succeeds!

Deploy. Get bug report after deploy that 6 + 7 should equal 13.

Write test case with that expectation.

Fix your sum method however you see fit your both test cases.

Repeat.

I implemented this test case because karma/grunt won't succeed if there isn't any test.

A common first test case is making a function which is easy to build but will give you an idea of the use of unit tests.

I don't see why I should write the same code twice. When I make a function and would already think about it's possible errors, I already fixed them. When I make a mistake, how could I be not aware of it while making these weird test cases. My unit testing is in my head.

I know how it feels. But keep on, dude, like they say here, begin into TDD writing tests of things your software it's expected to do. Then write the code that make those tests pass.

@nnmrts Thats one of the reasons why you should always have somebody else write the tests for your own code.

@nnmrts You don't write it twice. You write certain code describing the expected behavior of other code.

And whereas it might seems almost trivial at times, remember that most bugs are not introduced by writing the first implementation but by adding new features and rewriting old code.

You still can juggle the entire code base in your head?

In the past, I was involved in projects where I was *forbidden* to write tests.

So in theory, I had to test all the features before deploy manually.

I didn't do that. I didn't take responsibility for regressions. So each deploy was based on hope.

I now only work on projects with both unit and integration tests. Never felt more confident about the code base.

@3picName I have heard this before that others should write the test cases. It always seemed odd to me.

Why wouldn't I as the author of a public interface not know what to expect as an output for certain inputs?

@matt961 yes its possible, im not sure what packages you can use but I know laravel has an implementation ready to use. Its not called unit testing if you are gonna do UI tests. I think its called implementation tests or end to end testing. Not sure which of the two is the UI tests.

@matt961 there are three types of tests.
Unit tests tests small functions seperately and run during development.
E2E tests takes a bit longer to execute so we normally run this once every sprint.
And then there is another type of test which I think also tests ui interaction but Im not sure what its called.

Never understood why people bitch about the size of node modules? You low on disk space? Is disk space expensive where you're at? Are you on Mars?
Forsize on disk is the least of my concerns

I think 1+1 is not 2

There was a blog post by somebody talking about why you should always check node modules. Cause it's too heavy. In of the module, in every file, the author put his image. I don't even know why. That's why check your modules all the time.

@nnmrts unit testing will allow you to automatically check if something you changed in one part of the code breaks something in another. Say you have a webshop, and you decide you wanna display rounded prices. Suddenly your VAT calculation is wrong, because you're rounding a value that is later used in that calculation, but also happens to end up on the front end.
Your unit test will tell you before your customer sues you for causing them losses, or fines from the state.

You simply can't keep track of everything once your project becomes bigger, or other people start working on it, who may not have this map that you have in your head of the code.

When you're working on small hobby projects unit testing doesn't have much value.

Just wait til you move into larger professional projects where code is often refactored by multiple people.

@Codex404 Functional testing, I think. Puppeteer is one example, you write instructions performed my [optionally headless] chromium browsers. The test moves the cursor to selectors, populates inputs, asserts that pages change the way you want them to.

It's pretty handy when you're making changes on any level and want to confirm you didn't break anything on an abstract level.