To unit test or not to unit test?

When it comes to personal projects I generally write tests only for code/features I do not yet fully know how to implement. The test runner offers a handy execution env without needing to code a UI. Also, I tend to write integration tests when connecting to 3rd party services. Also to have some actual execution against your code and verify the integration. Generally, this leads to about 30-40% coverage, which includes the hard bit by default. That's my sweet spot for personal projects.

WARNING: if someone is paying you to code, write the freakin' tests, and DO NOT follow my initial advice.

WARNING 2: if you or your team is tasked with long-term dev on the system, also write the freakin' tests! :-)

"Eat your veggies and write your tests".

Many people think that writing tests will make you go slower. But that's simply not true. Yeah, you can ship something faster if not a single test is written, but that initial speed will eventually (in a few weeks) be blocked by the technical debt left behind. And getting up to speed again will be painfully slow and expensive.

On the other hand, writing tests for absolutely everything is not practical, specially for a bootstrapped company or indie hacker with limited resources. So the key is to know what to test and at what stage. Some rules I follow to decide if I need to write tests:

1) Critical functionality. Core, high-usage parts or the ones that would cause a big disruption of the users workflow if broken.

2) Complex parts. If certain functionality was difficult to write today, it'll be at least 5 times harder to fix if broken in a few months. Multiply that by at least 3 if it's a different person that has to fix it.

3) Time sensitivity. How long can the user wait for a resolution if broken? If your "Reports" page is not loading, no big deal. Worst case scenario, your user can live without reports for a few days. Other parts cannot wait because users interact with them frequently.

4) Major / Critical bugs. You fixed it, now you write a regression test to make sure it doesn't happen again. Not the trivial ones, but the ones that impact the system in a bad way.

As you get more resources and the product matures, you can slowly increase your test coverage as you augment the different parts of the system.

I’d say write rather E2E tests. That makes sure the user gets what you announce on your landing page. Plus when it’s Running with your CI you make sure you didn’t break a function while developing a new feature

IMO tests are an investment in your product.

I can't count the number of times an obscure unit test written 6+ months ago has saved me from deploying a complex bug.

Definitely not, only for complex/ critical parts where a test is actually appropriate. I know a lot of devs who get bent out of shape about testing every little thing because "it's the right thing to do", but I don't buy it.

I think basic smoke tests (one for each page that ensures the page will render) are enough for most situations.

The term technical debt implies to me you can avoid paying for it up front out of cashflow/time/money (writing tests), or pay for it later at an interest rate (pile on more debt). If the trade off to writing unit tests are slower initial development with the goal of avoiding long term technical debt, then you have to figure out the appropriate balance of rapid development VS stable product for your product. For pre-product/market fit, I think incurring technical debt you may never have to pay off if your product fails makes sense. The trick would be if your product is successful, balancing whether you'll need massive refactoring later or an entire rewrite (technical debt default).

Here is another perspective.

Although there is some ambiguity around test categories, unit testing usually means testing the smallest possible units of code, and directly testing the code itself.

I rather not do that, because it is easy to fall into the trap of testing the implementation details when writing unit tests. You should not care how your app works. You should care that it works, from a user's perspective. Especially at the early stage. Let's unwrap that.

By not testing the "how", I mean that you should not test if calling the create_the_product() function executes a INSERT INTO products ... query to your database. That's called testing an implementation detail.

What's 100x better -in my experience- is this:

• Make a request to POST /products with the expected input.
• Test that it does not show errors on the page.
• Make a request to GET /products.
• Test that you see one product on that page and the name is the same as your input.
• Make a request to POST /products with wrong input.
• Test that it says what was wrong with your input.
• Make a request to GET /products.
• Test that there is still only one product and the name is not your latest input.

Write tests as if you were a user, and assert what you expect the app to do. Your users don't care what SQL you execute, or which cache mechanisms you use. So shouldn't your tests.

Test the core features first. Don't forget to write some integration tests as well to test a module as a whole.

Do you feel yourself loosing control over your codebase? Are you scared to introduce changes? Do you feel that your app is a house of cards that can fall apart any second?

Write tests.

Are you cofident that your application works well (in general)? Do you see only small bugs appearing? Do you know what is going on in the whole codebase and it's easy to manage?

Don't write tests.

When I'm being too lazy to write tests for everything, I follow one simple rule:

If I broke something in production, I absolutely must write a test to simulate the issue, fix the issue and effectively ensure I never have to waste my time fixing it again.

On the "oh crap" stuff, yes. Things like making sure you don't charge someone the wrong thing or incorrectly write some complex data to the database.

I like DHH's take on this (paraphrasing): just write tests for the stuff that you're not certain will work as you expect every single time. Or, refactor that stuff if you think you can get it close to that point.

It depends what kind of your product. One of reason for unit test is prevent unexpected error made by others who didn't know the code he wrote will make error on another place wrote by another person. If you develop everything by yourself, you will know what's will be happened.

In fact, the most of error occurred while developing an app is about UI and logical mistake. The unit test can not 100% guarantee for that. You still need to use and try every features of your app to made it perfect.

Testing costs time and never guarantees that everything works. I was red a good article (can't find it) but the gist was: I rather have good monitoring then good testing. And I agree with that.

1. Monitoring, know what is going on in year app/backend
2. E2E tests. I recorded several important flows like login, likes plays etc. If this isn't working I start digging before deploys. Yes a full test suite will tell me what is wrong faster but since I build all the code I have enough domain knowledge for where to look!

I am pretty much doing it like you, for my project I didn't want to waste time writing tests and wanted to get the product out there as quickly as possible. As a result I broke some stuff several times...
I once broke the very home page, and I was seeing several new user sign up and then hit the error, to never come back again.

Now that the product is out I take time to write extensive tests, especially for core features that I really don't want to break. If I were to do it again, I would probably write a minimum amount of unit tests to avoid breaking stuff very early in the product's life.