What sucks about testing?

People not sticking with doing tests... they are hyped on the first week and later just abandon them, introducing workarounds to skip tests when something fails, making it a burden... and finally delete it from the code base

In my experience, the thing that sucks about unit and integration testing is you never know if all the different pieces always work nicely together, you need e2e tests to make sure of that. Over the last few years, I think the popularity of really complex SPAs connecting to multiple APIs has made this much worse.

And the thing that sucks about end-to-end tests is they're hard to setup and maintain, especially if you have junior/intermediate developers on the team with little to no automated testing experience. Tools like Cypress improved this a bit, but even that wasn't enough for the development teams I've been part of.

That's why I wish I could use my current product a year ago to create tests for the products I was building at my job. If you're interested in e2e testing and you're open to sharing your thoughts and feedback, I'd be happy to raise your quota so you can use my product for free as much as you want: https://browseai.com/test

I've been writing tests using Cypress, Mocha, Chai for about two years now. I've been told i'm good at it. I don't think tests are needed for an MVP but in the medium term you should start building them out gradually if you can't afford to have people dedicated to it.

Frankly, I think that testing should be done first in-house and then by the public or third-party that has no idea how the app or website works.

During the in-house testing, what I found to be hard to do is to avoid trying to use the app as intended. As the developer, I tend to use it as it was intended, making it almost impossible to find bugs or things that might malfunction.

That is why I asked my colleague to do the testing as his role is not in the development part of the project. Since this is a 2 man army, we can't expect much from in-house testing, but we did manage to find a few bugs that were caused by specific scenarios that might happen rarely.

When it comes to beta testing or public testing, I think that the least favorite thing is finding the right testers. People that genuinely like your project, want to help and will give their best to do their testing job. Once you find those people, I think it is just a matter of time until you have a fully functional and "bug-free" app. Of course, 100% bug-free is almost impossible to achieve on smaller teams, but you might succeed. :)

"If you're having test problems, I feel bad for you son
I've got 99 problems but a test ain't one"

Automated tests are invaluable. If you were writing code for me, I'd want to know that you had made sure it was correct every time you changed it. However slow or brittle automated tests may be, they are much faster and more stable than manual testing. I suppose the only remaining third option is not testing. (shiver)

I've been on teams that really adopted a TDD practice, and they didn't have any of these problems. It's really hard to change your behavior to really use TDD, but it works.

All you have to do is:

• actually write the test first
• seriously, don't write any app code until you have a failing test
• then write only the code you need to make the test pass
• (optional) refactor

I promise you that the code under test will "magically" become faster and less fragile if written this way. (Actually, it happens because you're forced to think in clear terms about how your code is going to get called before you write it. The magic was in you all along!)

If your team is struggling with this behavior change, feel free to contact me, and for a substantial consulting rate, I will be happy to keep repeating what I wrote above until your team submits.

Testing multiple versions of something is hard. I.e, testing your empty state page when you already have data.

The best way I found was to have loads of accounts, but seems long-winded.