Why I am so obsessed with tests

Should you be the biggest power user of the application you're buiding? YES.

But how? You're coding all day. You don't spend 100% of your awake time using your application.

That's a shame because there can be a gap between what you think your app is (your code) and how users perceive it.

However you probably shouldn't spend more than 50% of your day using your app, if you are the person coding it. It's probably too high of a ratio.

So how do you become the biggest power user of your app if you can't spend more than 50% of your awake time on it?

The answer is you create users. You create tests. In particular e2e tests. e2e tests act like users of your application.

Yes, e2e tests are slow, yes, they're complex, yes they can be very flaky.

But if you go through these pains, it is so worth it.

So I am obsessed with tests because they're the only way for me to be both the biggest power user of my application while remaining the main developer of it.

In fact, I plan on creating auto users that deliver value for me using Bluewind.

Think of auto users as tests, but running for a real purpose, and to solve a real problem.

I also think that this concept of auto users is key to understand AI agents. Yes, I am building a tool right now. But I only build this tool because I couldn't find the right tool in the market.

However tools are not really disruptive, we've been building theses SaaS for decades now. The real breakthrough is to build tool users, auto users, AI agents. Things that use Bluewind to get stuff done. Like an employee would use google sheets, slack and mailchimp to deliver business impact.

Your employee is not a tool, it's a tool user. And for that reason, building tests is very similar to building digital employees, which is why I am so fund of them.

I also think that understanding tests is critical, which is why I am into UI tests. Yes, these tests are brittle, but again, if you find ways to solve the brittleness, you get so much out of them.

We still didn't create the perfect framework that unifies UI tests and documentation. Think about it: if I write a test describing how the app should behave, why not derive documentation from it?

(tangent) As I am working, I realize more and more that there is more to Bluewind than just unifying GTM, customer support, knowledge base, meeting transcriptions, email marketing in one tool.

The effort has to be made accross the whole Software development lifecycle too. Because Bluewind is a huge product effort. The only way I build all these features is by mastering the SDLC too. Look into odoo.sh: they're not just an ERP, they help you ship the ERP. The ERP is the app as much as it is the way you get the app. Everything is one. And I know this sounds woowoo, but it's just true. Which is also why I believe small teams will get more done in the future: when you go past 10 people in an org, people are going to start wanting to specialize in stuff. And now you face the same problems I am trying to solve in SaaS: integrations. But integrations of humans. Microservices solves a human integrations problem. And I believe that if you stop trying to solve SaaS integrations and human integrations, you can really build a much better product than what's out there. Because integrations in general suck. Whether it's integrating humans or software. The first question we should ask ourselves in an integration problem is not "how?" but "why?"