ah, so here we are. the long-awaited part three of my testcontainers saga. the finale? definitely. but not for the reasons you might think. spoiler alert: i’ve been wasting my time. and maybe you have too.

let’s recap: in part one, i introduced testcontainers as this revolutionary approach to integration testing. in part two, i refined the approach with better test helpers and more comprehensive scenarios.

and now, in part three, i’m going to tell you why i’ve completely abandoned all testing when it comes to my saas project. yes, you read that right. all of it.

the brutal realization

here’s the thing: when you’re a solo developer building a saas product in your spare time, you have an extremely limited resource - time. and time spent writing exhaustive tests is time not spent actually building your product.

it hit me like a ton of bricks about three weeks into my testcontainers journey. i had this beautiful, comprehensive test suite that could:

• spin up postgres containers
• run migrations
• validate domain entities
• test concurrent operations
• handle edge cases

all automatically. it was a thing of beauty. truly.

and then i looked at my product backlog and realized i had spent approximately 40% of my development time writing tests for functionality that:

1. hadn’t been used by a single customer (because i didn’t have any)
2. might completely change as requirements evolved
3. honestly, might not even be part of the final product

the stages of testing enlightenment

my former qa lead at adidas, patricia (who has a blog where she writes about testing methodologies with the enthusiasm of someone who’s never had to ship a product under deadline), would probably have a heart attack reading this.

sorry patricia, but i’ve reached what i call “testing enlightenment stage three” and you’re still stuck at stage two.

here are the three stages of testing enlightenment:

stage one: the wild west

no tests at all. just push to production and pray.

stage two: the zealot

ALL THE TESTS! unit tests! integration tests! end-to-end tests! tests for your tests! test coverage reports framed on the wall!

stage three: the pragmatist

realizing all of that is bullshit for a solo developer and embracing the chaos of no tests whatsoever.

i’m firmly in stage three now. it’s not just liberating - it’s goddamn revolutionary.

why no tests might be the best tests

this might sound like complete heresy, but hear me out: the best testing strategy for a solo saas developer might be no testing strategy at all.

think about it:

1. you have no customers yet, so what exactly is breaking?
2. you’re the only developer, so you know exactly what the code is supposed to do
3. you can manually test faster than you can write automated tests
4. requirements change constantly in early development

a cautionary tale: my over-tested fighter promotion system

let me give you a concrete example. i spent approximately four days setting up a comprehensive test suite for my fighter promotion system. it needed to validate the relationship between belt progressions, check eligibility based on fight history, calculate promotion points, all that stuff.

func (suite *FighterPromotionTestSuite) TestBeltProgressionValidation() {
    // ~40 lines of beautiful test code
}

func (suite *FighterPromotionTestSuite) TestPromotionEligibility() {
    // ~35 lines of stunning assertions
}

func (suite *FighterPromotionTestSuite) TestEdgeCaseScenarios() {
    // ~60 lines of test code that would make your CS professor weep with joy
}

know what happened two weeks later? i completely changed the promotion system after talking to exactly one potential customer who said “that’s not how our gym does it.”

four days of testing work, completely wasted. and this pattern repeated itself over and over.

the liberation of testing in production

so what’s my approach now?

1. build features as fast as possible
2. test manually (briefly) before pushing
3. push to production
4. let early users find the bugs

is this approach somewhat chaotic? absolutely.

will it break sometimes? definitely.

does it allow me to build 3-4x faster? without a doubt.

addressing the testing zealots

i can already hear the gasps of horror from the testing zealots. “but what about reliability? what about quality?”

my counter-question: what’s more important - a perfectly tested product nobody uses, or a somewhat buggy product that actually solves someone’s problem?

why “testing in production” isn’t as crazy as it sounds

for an early-stage saas with few or no users, production is your test environment.

and that’s actually fine because:

1. few users = low impact of failures
2. most bugs are obvious when you actually use the system
3. real user feedback > test cases you imagine
4. fixing bugs in response to real feedback builds customer loyalty

sure, don’t do this if you’re building medical software or banking systems. but for most saas products? the risks are dramatically overblown.

the special rant about unit tests

integration tests are at least testing something real. unit tests, on the other hand, are often just testing that you can write the same logic twice.

consider this unit test:

func TestCalculatePromotionPoints(t *testing.T) {
    points := CalculatePromotionPoints(5, 2, 1)
    assert.Equal(t, 17, points)
}

what are you actually testing here? that 53 + 21 = 17? or that you implemented the formula correctly? it’s often just a test that you can do basic math.

for complex business logic, sure, maybe write a few unit tests. for everything else? waste of time.

my new testing philosophy

here’s my new, gloriously liberated testing philosophy:

1. no tests whatsoever

just code and ship

2. manual testing only

click around a bit before deploying

3. fix bugs when users report them

not before

4. document known issues

instead of fixing non-critical bugs

5. embrace the chaos

it’s actually kind of fun

the real metrics that matter

forget test coverage. these are the metrics that actually matter for a solo saas:

1. time to ship new features
2. number of paying customers
3. revenue

notice how “percentage of code covered by tests” isn’t on that list? there’s a reason for that.

conclusion

let me be crystal clear: testcontainers are awesome. integration tests are valuable. comprehensive test suites are good engineering practice.

for big teams. with established products. and lots of resources.

for solo developers building from scratch? they’re mostly a waste of time.

my next series will be “how i built a saas without losing my girlfriend,” where i’ll go into detail about actually shipping something instead of just testing it.

until then, happy coding, and remember: sometimes the best test suite is no test suite at all.

patricia, if you’re reading this, i still respect you. you’re just wrong about testing for solo founders. let’s grab a coffee sometime and argue about it.