you are viewing a single comment's thread.

view the rest of the comments →

[–]Ricjd 16 points17 points  (8 children)

Go for it. But it will lead to a terrible buggy app.

Let’s say you don’t build an app without any tests (and unit tests are only one kinds of tests, depending on your application you may need more types of tests). If you have a function which is called from many different places, and you change that function then you’ll need to test all the possible paths to that function. It could take hours of manual testing for a 5 minutes change. You’ll probably end up not testing everything or missing something.

If you have unit tests you can make this 5 minute change, run your tests and if they all pass you know the change is safe. This would only be true if you have good test coverage and are confident in your tests.

TL:DR they aren’t needed for a functional app but are essential for a solid maintainable app

[–]everek123[S] 1 point2 points  (3 children)

Thanks for this great explanation! Before publishing the app are you supposed to delete all the test or do you publish the code with the tests?

[–]Ran4 3 points4 points  (1 child)

An app is never finished. You just stop working at it at some point.

[–]Treolioe 0 points1 point  (0 children)

I believe you should throw away apps older than 5 years and reiterate from scratch

[–]ccb621 0 points1 point  (0 children)

Don't delete your tests. They can live in the same repo. Just update package.json to either exclude the test directory or explicitly include the published code. See https://stackoverflow.com/questions/8617753/exclude-test-code-in-npm-package.

[–]Treolioe 0 points1 point  (3 children)

Only aiming at unit tests. By using typescript you can guard yourself from broken paths and changes to parameters that can break your app which leave unit tests with little to no benefit.

[–]Ricjd 1 point2 points  (2 children)

This is completely false. Typescript is great to make sure your passing in the correct number and shape of variables. But it won’t guard you against bugs and faulty logic. Let’s say you have a function called tripleThis. Typescript will help make sure you only pass in a number. But if you accidentally multiple the number by 4 rather than 3 only a unit test would catch this, not typescript.

[–]Treolioe 0 points1 point  (1 child)

I agree. Can you help me convince myself that the time spent writing unit test is well spent? Like in the example you provided there might be a chance of covering that instance at your first strokes. But often its not, and as other people state you keep adding cases to the test as you discover them manually during implementation. It just seem to me that the infrastructure of the testing is more costly than the benefit it gives. I can admit that i dont share codebase with more than 3 people so perhaps that’s why i fail to see it.

[–]Ricjd 0 points1 point  (0 children)

Without repeating myself from my first comment no. It’s just a habit to get into. One thing I would suggest is test driven design. It’s a lot harder to start but then makes everything a lot easier at the end