Why write tests for frontend when I can clearly see it works......I mean, c'mon, the like button is incrementing....this button doesn't like been tested (T-T)

Read a book
Unit testing by Vladimir Khorikov
This book is dedicated to explain this question thoroughly

@darkwind Thank you

It works today, you don't need a test.
Tomorrow, or 6 months from now, you change something that button interacts with, suddenly there's 3 likes per press.

Did you spot it early in a testing environment or did it go to production for 3 weeks before anyone noticed the "working button" is going to town wth likes?

Just because you can see something working, doesn't mean it will continue working the next time something even remotely related to an existing feature will still function the same without some form of testing.

You can do manual testing and spend weeks going through every possible scenario on a monolithic application, or you can write tests and automated the testing within minutes or potentially hours depending on the size of the application. Either way, it's not days and days of going through everything.

you need to test it every time you deploy. because: yes. even a thing as simple as a button can break.

and you need to write a test so _you_ don't have to test it - instead, the computer does it for you.

it's really testing 101.

Does it work in all the pages for all the user roles? Will it still work if you comment out line 47?

And most importantly, how long will it take for you to test all the scenarios?

I truly hope answering those questions will make you see the problem with manual testing

I went back and wrote the tests properly. I wasn't thinking that far ahead, and I really appreciate the advice, Dev Seniors.
Back to cultivation

Also project maturity, resource allocation and type of project matters. In ideation phase with frequent UX redesigns it's too costly to rewrite unit tests. Static landing page in New Year theme? Little logic and short span of time so unit tests are less relevant. Business-critical piece of logic or legal requirements etc, YES PLS.

I always come back to an argument I heard a Senior having with a Manager:

...... [20 min arguement] .......

M: "if it ain't broken don't fix it"

S: _how_ do you know it's not broken [without some sort of test]?

M: [completely silent]

S: how do you know it hasn't broken since then?

The senior won. We're allowed to write tests now 🥂

Tests are to stop people from breaking the code by mistake later on, not to see if the code works right now...

@YADU I disagree on the last point - e.g. tests are the first thing we run at our place when pulling down a new repo to make sure we've setup the environment correctly.
Another example is writing a characterisation tests for a bug to determine where the fault lies and why it fails - so seeing _how_ the code works _now_ before any change. Can then use that test to drive out the fix and now you have test coverage for it 🥂.

Writing characterisation tests for an area of legacy will help you prevent regressions yes, but also deepen your understanding of the legacy when making any kind of changes - a great activity for teams to-do we've found. Unearths a lot of lost tribal knowledge.

Is past midnight when I wrote this. Should be asleep sorry if rambly