For those who do Unit Testing...

I have always tried to write unit tests for pretty much everything, for most of a 20+ year career (I stumbled into the usefulness of thorough testing, entirely on my own, in my SECOND project at uni way back in 1988... the first had been messy and stressy, testing every single function as I wrote it made the 2nd one indescribably better...).

I once wrote a paper for a company I worked for on benefits and expected effort for proper testing (including integration testing, ui testing, testing the installs etc etc and the use of tools in automating testing). Using my experience and the info I found from research, I think I recall saying that the time to write (and test) unit tests takes 1-4 times the amount of time to write the code (but that overall development time TO CORRECTLY WORKING PRODUCT was reduced.

That's right - at least as long as the code itself and possibly FOUR times as long and by gawd is it worth it in sanity and calm (esp with good DevOps/continuous integration support). A release can become a real "nothing" event...

When you have testers in the team (highly recommended!!), IMO, you need a minimum of 1 per 2 devs, ideally 1:1 for any project with ui, just to keep the tests running at a pace that keeps up with development. Ideally they are experts who also write tests.

I am NOT a TDD as seems to be defined these days. I am iterative, but write far more bottom up, and I would always e.g. get a working database in preference to mocking (just my experience, mocking data is no quicker and very frequently fails to identify SERIOUS issues), but I DO write tests for almost every damn thing, (including database procedures etc) and make sure they keep current and passing. (Unless flat out not allowed to by management - but that isn't then a place I'd ideally work...).

Oh, and never attempt any significant refactoring without a good suite of tests (all types!). Or you are just flying totally without safeties (IMO):

I have worked in companies huge and tiny and I would say the same for both in principle - seems harsh, or overkill, but software should really work right without killing people with overtime and panic. I have seen it work well (and of course seen the opposite - that is why I have an opinion!!).

This is all just my opinion borne of my own experience. YMMV.

Hope this helps!

Well, it depends on the project timelines and the quality levels project is expected meet. Typically, at the start of the project, managers / architects push for "Test-first approach" or "Test-driven development" and slowly this initial enthusiasm gets carried away (my personal experience); although there are some projects that practice this religiously. That said, unit tests do help in the long run once they are integrated into test automation. You will certainly feel more confident if you get to know that the test suite (comprising of few hundreds or thousands of test cases) are running without issues when you do a change to the project (kind of proves that you didn't break the existing code).

Developing Unit Test cases takes time and imagination. Certainly there is a price to be paid for it beforehand, but it does reap benefits in the long run.

We have sites that contain 1,000+ javascript files along with weekly deployments to our production environment, modularized shared components across our projects, and many teams making changes to all of it at any given moment. Having a high threshold of testing coverage allows us to greatly reduce our regression testing efforts in this kind of environment. We also have Git hooks that will fail to push Git commits or break Jenkins builds if that threshold is not met from unit testing to help ensure that we do not let our quality degrade over time. We have used many different frameworks, mainly Mocha/Chai on our projects, and lately we have started using Jest which is awesome for testing our React apps. We definitely take our testing seriously and it pays off in the long run.

Thanks. It is a profession in which one is always learning ... :-)