Is unit testing necessary?

I think so

it isn't if you're not really relying on that piece of code or it is a small project that isn't made for intensive usage.
elsewise it isn't necessary but recommended to do so.
this test isn't flawless (could be though if executed precisely) but is a great indicator =)

Yes it is.

Neccesary, no. Does it prevent buggy code from being pushed without proper testing, make sure shit works the way it's supposed to etc, yes.

So not necessary but yeah it helps a fuckload!

No, unit tests are not necessary, but neither is breathing.

I don’t recommend not doing it but, each to their own.

Unit tests when done right will prevent bugged code from making its way through.

I use unit tests as a pre-commit hook for git so no code can be merged without passing the unit tests.

They will slow you down but the trade off is not having to fix a pre-tested issue later on unless it’s some wild edge case that everyone has failed to think about.

Its as necessary as writing readable code. You don't need it, but it helps.

I combine writing tests with writing the functions itself. I need to test them anyway and clicking through the application and running into breakpoints is not exactly more comfortable than test cases, especially when testing exceptions and irregular data.

For me it isn't more effort, it replaced other efford with some that creates tests as a side effect.

@C0D4 not breathing becomes a problem after 30 seconds

@MisterArie
I Should have tested for that 🤔

If you're writing complex code, the unit tests will be as complex as the code.

How do you write a unit test for a complex algorithm like data compression?

How do you unit test UI interaction?
You can't automate human vision

@theScientist I've done it on an internship and they tossed it because they changed a contant string by a little...

@repstosd
Data compression you would probably test the results to be as expected, unexpected as per any unit testing, I haven’t worked In this particular area to any depth before.

Front end testing can be done with many tools.

For web, as an example:

Selenium for automation for example, if you can’t automate your front end you have something insane or overly complex.

Also depending on front end language their is usually a unit testing framework to coincide.

The way to test a compressor is to compress data and decompress it.
The way to test a decompresor is to do the same.

This is a chicken and egg problem. You can't know if it's the test or the code that's broken, if it fails.

As for UI. You can never test for critical UI issues like "tooltip didn't disappear" or "this content overflows it's container"

You can mock a server, but you can't mock networks.

Test driven development and unit tests are overrated.

Is breathing necessary?

I'd also argue that even though they slow you down in theory (more code to write), in the long run they actually save you time when you're adding new features. For one you can easily make sure you're not breaking things when you push put new code.

@repstosd
Well you answered it yourself, you know how big the file is to begin with, and you have a decent idea of what it’s going to become when you compress / decompress. How can you not automate a test case for this?

As for UI, most tooltips work by injecting elements into a DOM, so by nature you test that has occurred and elements have been loaded.

Unfortunately I haven’t found a way to test for bad Designs, where text overflows or elements break, or sit in the wrong place.

something’s do need to be ran manually but why not automate what can be automated?

No. Actually, while your at it, don't even test your app. Just write your code and publish to production. Don't even question it

Unit test are for people who wear seat belts when riding in cars....

Does the Pope shit in the woods? Is winter coming? Does a lannister always pay his debt?

Jesus, son. What a question.

I never test my code and I always edit on production

My full-time job consists of unit and user testing. If it weren't for me, my company's product would've broken on launch. Yeah, totally necessary.

I actually really don't like unit testing, if it is so detailed, that you basically check if your code Has changed at all.

I prefer Integration testing over unit testing. With integration testing, you're not checking if your code has changed, but if your application still behaves the way you expect it to. And at the end of the day, this is way more important.

Unit tests are a huge overhead, with little gain (they don't necessarily tell you, if for example your api still gives correct answers), while integration tests are a smaller overhead and have a huge gain.

Unit tests tell you where you might have bugs (or where you haven't updated your tests), while integration tests tell you IF you have bugs. The latter one being far more important

@heikomat I disagree. Both are important test phases and one should not be used instead of the other.

Unit tests do add overhead initially, but for subsequent releases, the effort is less and the gains are greater. You can ensure that any new code added has not had an unexpected impact on existing code without retesting everything as you did first time around.

Especially useful if the developers working on the new release are not the same as those working on later releases.

Unit tests can pick up lower level defects that integration tests don't.

Unit tests can pick up problems earlier during the development phase so bugs can be picked up as they are created and therefore can be fixed before they cause further problems and less unpicking.