Solopreneurs: Do you write tests?

Usually very few tests.

When I do, it's usually either unit tests for something business-critical to get right (e.g. price calculation with a lot of factors), or UI-driven tests aka "is my website down or not?".

As with anything, I do believe that less than 20% of all possible tests provide 80% or more of the result.

IMHO, When you are small, most tests aren't worth writing. Additionally, they are a good source of procrastination.

When you are small, it's better to have more bugs but move much faster.

If you fail, it's incredibly unlikely that you fail because you are too buggy.

TBH, I was always a huge proponent for TDD. I used to work for a big insurance company, and the software there just needed that to fulfill some of the SLAs.

I kinda carried that over to my side projects and have now completely stopped writing tests. 9 out of 10 projects don't make any money anyway, or have little to no users.

I would say: focus on providing value first, iterate fast and when you run into problems or have specific thing that really really needs to work and doesn't change much (maybe something related to payment, etc.) then implement tests.

For the most part I found I don't need them. This may obviously vary depending on what you develop. Just my 2 cents

Never! Users will be the QA and tell you if something is broken.

Indie Hackers has almost no tests.

Tests are overrated.

First I write code to see if my biz logic is useful for my target audience.
Then I will write tests to see if my code is useful without bugs.

Good tests usually takes same amount of work needed to write the code .

For a penny and some crackers, I'll write tests for all the code out there. There's nothing more tragic than untested code.

I think it’s a must. Not only does it help ensure that your product is functioning properly and minimizes bugs but if you go to sell the rights to the product later on it’ll help you command a higher price because you have verifiable proof you have minimal bugs.

I've decided to just write for the parts that are critical to the business. I don't think it's necessary to have 100% coverage in the beginning of an idea/project when there's little usage and little impact.

Also in the beginning, while you're launching your idea, is very probable that your idea will change, with logic needing to change as well. Having always up-to-date tests doesn't seem effective.

The moment, a business starts growing, your codebase is more stable, and issues have a bigger impact, then it's time to get a bigger test coverage. It's true that at this time, you usually don't have the habit, and need to introduce it. Costs might be higher at that moment, but even so, IMO is worth waiting.

It depends on how big the project is going to be, but as a rule, yes.

If it is very small or just going to have a short shelf life, then I'll write minimal tests.

When I plan on working on the project for more than a month and/or quality is important, then I take the extra time to write more and better tests.

It's worth it to put in the little extra work to make sure everything goes smoothly in the future.

Adding 1 small feature a day with tests is a pretty realistic goal for me for personal/side projects.

It's a marathon, not a sprint.

I think of development, and test writing specifically, like going to the gym.

Sure, you could just go golfing/kayaking/skateboarding/whatever for 3 hours after work every day, but without proper muscle development and training your musculoskeletal system as a whole, you risk injury. Training your muscles/bones/tendons prevents injuries that will take you out of the game for weeks or months.

Same thing with testing. You spend a little bit of time now, and you will prevent yourself from making bad design errors that can take a lot of time to refactor.

It's definitely not as fun as just moving on to the next feature, but it might help if you don't think of it as separate from building a feature. It's half of it.

Another way of looking at it is like cleaning up. In restaurant kitchens, there is a saying, 'clean as you go, sign of a pro'. What would you think if you looked into a commercial kitchen and saw food scraps and spills all over the counters and floor? You would think they are a bunch of slobs who don't know what they're doing, right? They don't want a messy workspace either. It's unsanitary and it looks bad. You'll definitely see some cooks who have a sloppy workspace, but they will stand out from the professionals who wipe down their counters, sweep, and keep their knives clean.

Oh God this is a controversial topic :D

Having worked in the corporate dev world, tests were everything. Test coverage reports >90% were literal currency for pleasing managers. Like slipping them a 20. Or a 100 dollar bill, in inflation land.

For my SaaS endeavors I haven't bothered with it. Not because it's not necessary. Tests are totally necessary. I just don’t bother with them because it's not a revenue generating activity. And revenue is king in the beginning. And time is limited, especially as a solo founder.

Talking to users = revenue generating activity.
Marketing materials like video = revenue generating activity.
Feature requests = revenue generating activity.
Fixing bugs = revenue generating activity, by virtue of signaling a positive customer-developer relationship

That said, I always have testing in the back of my mind. I think when I reach a point where growth is self sustaining and the machine is running on its own, I head down that path.

But as solo founders, our time is just so damn valuable.

Automation is one of those things that can really multiply the capacity of solopreneur, and testing is one of the best examples. Without regression tests, any non-trivial change requires lots of manual testing time to avoid breaking existing functionality. That said, more tests means more accidentally flaky tests, which is why I also use Unflakable (shameless plug) to dogfood itself. It already managed to identify a couple of flaky tests I wrote.

In a couple of extreme cases, I have two open source plugins as part of the product that have to interoperate with multiple different versions of testing libraries. For that, exhaustive regression tests are an absolute must. In fact, the testing code is 2-3X the size of the code it's testing! Here's an example on GitHub. With this approach, I can confidently add features, fix bugs, or test compatibility with new PyTest releases without spending time on manual testing.

Yes, tests help with stronger confidence, reasoning, and organization. If you have a quick shortcut to generate the test scaffolding, it’s really not too bad.

Absolutely. And the tests are what gives me the confidence to move fast.

100%, yes. I use CI/CD, and having confidence that I'm not going to break things in production is paramount. I'm using Rails with Minitest and Capybara (alongside some other things in my CI pipeline like Rubocop, codespell, bundle audit, and brakeman).

As a solo dev, automated tests are like having a reliable buddy on the team

• Ignore tests pre-revenue, only MVP matters
• Post-revenue & actively developing - write those tests!
• E2E only - yes, they are painful to write & break easily, but they actually tell you whether your product works for customers - I don't bother writing unit or integration tests

Yes.

For me, automated tests are a big part of the QA strategy in shipping software that works. And that process working well is what enables high velocity. Getting good at writing tests is a skill that will serve you well in your career.

To echo somebody else's comments: mostly integration tests, with a few unit tests for tricky or mission-critical bits (many paths). And a massive amount of leaning on the type system / compiler to catch things before I have to run tests. You need to layer things in such a way to leverage your tests properly.

Sure, you can bikeshed with testing and chasing coverage, but if you do it smart you can end up going significantly faster when you aren't tripping on problems all the time. It just takes practice to get there.

Our strategy at Featurebase is this:
If we make money - we write tests.
If not - we don't write tests.

The main goal is to grow your MRR and wasting time writing tests doesn't get you there.

I write tests only when it is needed. Definitely not a big fan of 100% code coverage or things like that

I find it harder and harder to release new features since I worry too much to break something. I have no tests at the moment but I feel that it is probably time to add some.

Yeah, I enjoy BDD quite a lot.

I have very few unit tests. Most are integration. Some are e2e.

Absolutely necessary. As your project grows, you'll eventually come to a point where you don't remember every edge case that can happen. Putting that all in test code will give you the piece of mind to make major changes in the future without fear of breaking things. It's also a wiser use of your time to have that all automated through CI/CD so that every change made goes through every test created.

Strive for as close to 100% test coverage as possible.

I write tests extensively, but I also document pretty much everything (like type annotation, decision log, etc...).

It definitely takes much more time, but I wouldn't say I'm wasting it. There are two main reasons I made that decision:

• I'm building a tool for developers. I felt it was important to gain the trust of my peers even during early stage.
• The product I'm building requires access to one of the most critical asset of a software company: its codebase. I absolutely wanted to gain confidence in what I was building and ensure every security scenarios I could have in mind were tested for future regression.

IMO, not writing tests could make sense during the prototyping phase, but anything after that would be a no go for me. Especially if the target is software devs who knows their sh*t and can quickly tell if the product is reliable.

Absolutely not (until product market fit)

There is a strong case to write them for mission critical code like billing/payment/accounting but typically your payment processor has abstracted all the ways you can fail.

I think as a solopreneur, if you're writing tests before you hit product market fit you are burning your own time.

After PMF is found and revenue is flowing I think it's a great idea to wrap your core or error prone code with tests.

The trick is not giving away our most valuable weapon: Speed.

In my day job, working on systems that are already in production, I write unit/functional/visual tests quite religiously, otherwise really bad, company-threatening things can happen.

On my side project, design and architecture aren't overly bedded down at the moment, so in many cases I find writing tests would be premature and wasteful. But that's not always the case. For very important things that are locked down early, such authentication and authorization, I have really good integration test coverage in the backend.

As my SaaS approaches production, I'll write a lot of tests across the entire codebase to ensure the product doesn't all fall in a heap at launch.

If my prelaunch SaaS was a team effort, I'd insist on tests, otherwise we'd be breaking each other's work on a regular basis and that's a morale, productivity and project killer.

I do

But partially because it gives me a direction, so that means that I'm writing only feature tests most of the time. And it helps me speed up development as I don't have to be hitting the api manually all the time, just define what I expect as response and code until I get it right.

When it comes to E2E (Frontend -> API) tests, I've been a bit more 'neglecting'. Probably gonna leave it until revenue comes

Only for complex / critical logic segments of the code.

Not as much as I'd like to. I'd probably suggest writing functional test cases instead of writing unit test cases. Since a functional test while more difficult and tedius to write tests much more than a unit test could ever do.

So write a functional test , if that's the only thing you write.

PS -> This goes against all technically advice(which says you should be following the testing pyramid),but since you are solo, you have no option really.

And yes, your future self will more than thank you for writing any sort of tests.

I did tests, but they were not 100% accurate since I was doing narrowed experiments.
The real testing sometimes is tracking errors with frameworks like New Relic or constantly tracking error_logs and performance issues.
Sometimes using a function in a deprecated library might consume a lot of resources of your service. Mostly DB Queries from MySQL might consume all resources, that's why many use a Cached NoSQL Redis alternative with Varnish. But you can also use the ElasticSearch service.
A big discussion about this. Like when coding Python, most coders say in the subculture, what is the most Pythonic way? The question here, is what is the best architecture?

On early stages or projects with limited resources I don't create tests. Instead I create checklists to keep track of things worth checking to not worry I forgot something. Later on I might convert some of those to tests.

Here is another thread with similar discussion - https://www.indiehackers.com/post/testing-on-solo-developer-projects-how-effcbdaf59?commentId=-N5ZX3t8o4hYBBXRQGo8

Only the most important ones until my project takes off. These tests are all on my server to make sure that I don't, for example, remove the admin restriction from some API route.

Ship it fast. ⛴

Later, you can write tests.

I think testing is necessary to make sure the code you wrote is actually solving the problem you thought it was.

That said, I think there's a balance between:

• Valuable tests
• Tests for test's sake

I think most of this probably comes down to:

• Writing code that is highly testable
• Writing tests that are actually useful (what is this trying to do vs how is this doing it)

So far, I've found this approach to be best to make this tradeoff:

• Write tests while writing code (Red, Green, Refactor method)
• Only test the public API (how this code is supposed to be used)
• Cover the main cases

This seems to provide a tight feedback loop (which makes coding faster) while also making sure the tests are valuable - both in what they cover and how they cover it.

Side note: I never really believed in TDD as a productivity tool until I saw these vids that explained how to actually make it productive. Not my vids, but am a huge fan: https://twitter.com/SIRHAMY/status/1408476094131539969?s=20&t=jv1EY2XzWH3-3P8VEC5Ahw

I think it makes sense to choose where to spend effort writing tests. Concurrent code is difficult to get right and can benefit from lots of tests. Security code should be tested. A lot of code you can test manually with little effort.

If I’m really early into an idea I’ll skip tests, lints, types and just hack something together. If its got legs then I’ll bring those parts in. Tools like cypress are great if you want to tackle the top of the pyramid (E2E) because they likely give the most confidence. What I would say though is use good architecture and patterns early so you at least know your code is testable.

I write tests. Not as many as I should but some, especially around the critical functionality.

And plenty of times I’ve made a change and it broke something else which was picked up by the tests.

Good tests give you the confidence to make a change and quickly deploy.

yes i think you have to write test for some reasonable ones

I write tests for critical functionality, like the security rules for Firebase, which determine access to the database. Also, a few UI tests save time on every deployment to check that all basic functionality is still working as expected.

we don't do that here, we do sales, not tests (it's in my case)

I don't until I absolutely have to.
And for payment purchase flows I kinda need to because I tend to change the UX a lot.
And if I don't write the test case I feel less confident of when it worked.

For the backend yes. Most of the times it lets me iterate fast. Especially on purely logic code.
I test mostly happy paths though.

I am not a fan of TDD Test driven development at fabform.io . I am a fan of CBD
Customer Buying Development.

No usually my projects are mvp's so I write the code as fast as possible and launch as fast as possible a product that works.

I try to have good test coverage for core business logic. For everything else, I do a quick mental calculation as to whether the cost/benefit ratio of writing a test makes sense. Testing the right things can improve velocity, but writing superfluous tests can slow you down.

My new product coming out soon Test Not - https://testnot.com

I write tests for everything in getparthenon.com because it's a SaaS boilplate so something that is being released and people depend on to work for building their applications. So everything is unit tested and then functional tested, with 5-6 test suites to test various configuration options and then tests ran on in-house application built on it to ensure no breaking changes. Most of my GitHub actions minutes are spent on these tests.

For my SaaS, I'm a little bit more lenient. I'm about to add some more tests to things that are super important and I need to work. It's easy for me to add features to something and forget about all the other use cases. Mainly adding database fields. So I'm going to start adding tests on the most crucial features of https://blether.chat which are Creating a site and creating a chat conversation.

When I started out with side projects, I unit tested everything and then had integration tests, and functional tests. I did what I really wanted to do. However, I noticed that often I would just lose interest and I would spend a large amount of time and achieve nothing. I then moved over to doing just functional tests on the most important functionality. This gave me the overall the best of both worlds, I could move rapid fast and not spend time testing code that may never be used by anyone but also give me a security net of some tests to make sure I don't break everything and not notice. I'm human, I'm not going to do a full end-to-end test every time I make a 5 line change.

I have extracted essential business logic into pure functions and test those with unit test. Fast and easy.

Further down the road I will expand testing and run them with Github action on PRs.

Mostly functional tests but not a lot of automated tests like units one.
As long as you’re small, the lack of tests is unlikely to be the cause of failure and you should move forward.
When you become bigger, it starts to become interesting for business critical area of the software but otherwise they are just a waste of time in most case.

Obviously, the bigger the org and the more critical the unit, the higher the need for test will be.

As a matter of example, I help grow Edith & Nous to 15k+MRR without any automated tests nor the need to write one 😊

yes, i am absent minded and test suite helps me sleep peacefully at night. I am 100% sure that if i don't write tests i will miss something or the other. Golang has in built testing framework i use that.

I started to contract test my APIs, essentially I am using jest to write test against my public API.

Why? Because I am lazy, sure I could trigger the endpoint manually using Postman or insomnia but doing that for multiple success and error cases becomes tedious and on top of that I have to manual generate and/or delete the data from the DB in case there are any conflicts (e.g. duplicate keys).

The software being tested is just an added benefit, on top of that it also validates my TypeScript types.

For a new product I'm building, a desktop app built in C++ with its core being a library which would later be used as SDK, I do develop tests because until I have a full app built I cannot properly make sure the code works other than excersising it somehow, and tests are such a way.

For other products I had already built, I only wrote tests for the most intricate logic parts. Those that I wasn't sure at first how they were going to work in the UI and most importantly, should remain in working condition after changes.

I feel if you do it payoff, and if you start late there will always be something that looks more urgent.

Not yet, but I plan to! – once the abstractions have settled enough so they're not changing every other week :D

Well I kind of have to, since I am literally building a product in the testing industry :D
But honestly - Normally, I get the MVP shipped first, then write tests, it's tedious but has to be done. Better than having unhappy customers or even churn because of some things not working as expected :)

I write tests just for complex pieces of code. In these cases, it's really helpful, since I make sure everything is working as expected.

But for regular code, I don't really care, I'd rather fix it later if I break something by mistake.

I use jest for tests since the stack I'm using is TS/JS-based.

Yes, as much as they pay off.

I write tests for important things. Authentication/Authorization, complicated computations etc. I use functional programming with Clojure so kind of low friction to add tests and it feels very natural to the development flow.

No specific framework. I've written some about my process here: https://blog.wobaka.com/how-i-use-clojure-to-build-and-scale-my-saas/

Not doing any unit testing here yet.

A comment a lot of others would make is that at the early stages just focus on getting something built and your first customers on board. Only worry about scale when you actually need to. Up until then it's time you could spend on features or other stuff.

In addition to basic integration tests, I use Headlamp - https://HeadlampTest.com - to ensure I've at least touched everything.

I also use Headlamp to see the amount of UI coverage I'm getting from tests scripted in Selenium.

Oh and yes, Headlamp is my own service that I'm just now opening up to the public. Please give it a try and send me feedback!

Nope, I don't really have tests, and I'm okay with it. If I worked for someone else, I probably would write more tests.

I do a ton of manual integration tests when I'm writing a new feature or modifying an existing one. It's worked well for me. I target the most common scenarios, and if I find really, really edge cases that don't quite work, I do my best to fix those, but honestly, it's okay if it gets shipped.

I don't have enough users or paying customers, so my focus is really to build up features that I can market and attract more customers. Writing unit tests for me doesn't provide enough return on investment to justify. I'm more likely to fail at my project due to not enough interest/paying customers than too many bugs.

If I was a more junior dev, however, I wouldn't necessarily do it this way. Having a lot of dev experience helps to ensure I don't introduce too many bugs, and if I do, I'm pretty good at figuring out the cause and fixing it right away.