Hey solo-devs, how do you test your applications?

IMHO the most important thing pre product market fit is pace of change.

That doesn't mean I don't write tests, quite the opposite. A good test suite can give you enhanced velocity due to confidence and time savings in between deploys.

As an example, with WrestlingIQ, I have a lot of test coverage around the things core to the business. The only cypress tests are around accepting payment & camp registration. Ditto at the model layer, the tests I lean into hard are around the complex parts of my app I need to iterate quickly on without breaking. The gives me a personal sense of confidence and then I do a quick manual test run pre deploy of the changes I've made.

Do I have some controller tests, helpers, etc? Sure, most of it is DRYed up enough to slap common tests into a class, but I don't waste time worrying about code coverage or anything silly like that at this early stage.

I guess what I'm trying to say is that code is a lever - only you get to decide where to apply testing to maximize your productivity or safety.

It's tough to find the right balance. The right answer is probably not 100% test coverage, nor is it 0%.

An approach that seems to work for me is something like this: every time you push a code change and something breaks, write a test so it doesn't happen again.

Ideally, you get the confidence and reliability to continue fast paced development, without spending a disproportionate amount of time writing tests.

I used to be obsessed with testing when I made my first indie apps. I was carrying the big company thinking with me. In my latest venture, I am nearing 20K MAUs and still haven't written a single test. However, I have invested time in setting up proper monitoring / alerting with Sentry, NewRelic, and a proper development environment which is a near replica of production. This lets me manually test new features end to end and catch any regressions quickly. Not sure if it is the best approach, but it has worked well for me so far.

With alot of patience :)

Seriously though it depends on what you are testing and what platforms you are developing with. In the past I have just scripted out web api calls and retrieved the data back and confirmed scenarios with dta pased and retrieved.

As most of the time the middleware is the bridge between the client and the database this is a great way of getting a baseline and this can also be something you just set off and grab a coffee .... does also mean you need to be 100% on top of the scenarios and the models when they change etc.,

Another great way is to use something like Cucumber for TDD and of course pipelines for testing is good too. Microsoft also have a mobile toolkit in Azure from my understanding, the name skips my mind, that spans across multiple platforms for iOS/Android etc., however we use Xamarin so it has it's own tools for testing.

I don't have a personal project right now, but at work I unit test everything. Or more precisely; I TDD everything. I almost never do e2e testing or integrations tests either. I do some exploratory testing once I'm done, running through the scenario / use case / feature I just implemented.

The reason is that integration and e2d tests are brittle, slow and really expensive to maintain. It requires a huge amount of instrumentation to make them even just run. They are also not helpful once they break; if the test fails, you have no idea what's wrong.

Instead I wrap every "side-effect" producing part of my code so that I can fake it in my test suit. I also make sure to have well defined boundaries in my code base, meaning that faking dependencies is trivial.

As for maintaining test code; I rarely have a problem with that. I write my test suite as an executable specification. If the specification changes and makes a test "wrong", then I just delete the test.

This was a profound insight for me a couple of years ago; all the expensive tests that broke all the time were never directly tied to business objectives or features. They were tied to implementation details.

I could never work as a software developer without TDD anymore.

I like to think about tests as investments. In the short run they aren'g going to net you much value or saved time. But every single time you change code (e.g. add a feature) that test is paying you back. It might catch a small bug that will only take a minute or two to fix. But that minute adds up. And when you add on deployment time, finding the bug in your reporting tool, waiting for a user to notice it and complain, etc. the time adds up quickly.

Also, even if you are still "exploring" and trying to find market fit those tests aren't useless. If you have to pivot then you can change what you need to change and be confident that everything else still works as it should.

The main takeaway is that they are part of the development cycle, not something thrown in at the end.

I usually try to estimate how integral is that part of the product. Is it your core feature that is fundamental to your product? That's where I would want automated tests to make sure all the cases are covered.

Other parts where iteration speed is more important, I quite often skip automated tests. Writing testing code takes time and adds an overhead of maintenance. I rather solve one problem at a time - implementing a feature / writing maintainable code / automated thorough testing of the feature. All 3 are different problems. And not all need to solved depending on the what part of the product you're working on.

In my codebase there are just a few part which are properly covered with tests. Someone when working to solve a hard to find but I start writing tests in order to quickly validate whether it's gone or not.

In order to guarantee stability I'm usually working with generic logic. Write it once, and apply it everywhere. This way the whole API surface is pretty stable without any tests covering it. Some of the absolutely critical components for data processing are extensively tested though.

Additionally I'm deploying quickly (almost every other day now), and sometimes breaking things as a result. In order to tackle this I'm monitoring all components using Sentry. If something breaks I can be sure I have the information I need to solve it.