Touca is shutting down
touca.io
touca.io
I can relate to that and that’s a very mature and honest way to handle things… it takes great self-awareness knowing when to quit.
More on this topic can be found in the book The Dip by Seth Godin… quitting is OK and shouldn’t be seen as failure.
Summary here: https://medium.com/@thenoahdouglas/what-i-learned-about-quit...
Anyway, recharge and then on to the next adventure ;)
I think this is a great quote to show that you should be focused on creating must-have products. Not nice-to-have ones.
Sadly, building a must-have developer tools product is incredibly difficult as users are often not the primary buyers. One trick that some founders use is to postpone launching for real until after they raise one or multiple rounds. This way, they won't be held accountable for growth and revenue numbers. But that's dangerous since they can build for years with confidence, not realizing the flaws in their product positioning.
Startups are just really hard...
Having said that, our v2 launch last month was on the front page for about a day: https://news.ycombinator.com/item?id=34959276 ...but it was too little too late.
I wanted a name that is easy to type on the command-line (since that's the interface for many users), easy to pronounce, and somewhat meaningless in English. Touca was the best I could think of. :)
> Despite growing usage, we had not yet found product-market fit when the down market started. We failed to secure more funding. Our revenue declined as some of our largest customers downgraded to cut costs. In the process to convert our nice-to-have product to a must-have, we burnt out.
To clarify, you were competing with: when somebody opens a pull request on GitHub, GitHub actions (or a webhook to Teamcity or Jenkins or whatever) runs "cargo test/npm test/dotnet test/whatever", right?
In a perfect world, what did you expect adoption to look like? How would you get people off of the flow I just described?
We were not competing with or replacing GitHub Actions so the flow that you described wouldn't change. If you were to use Touca, you would continue to run "cargo test/npm test/dotnet test/whatever" that are likely running unit tests and integration tests.
Touca tests are more like snapshot tests and property-based testing in that you wouldn't specify expected values. You could run them locally or on CI or on a dedicated machine.
You would write high-level regression tests using our SDKs in Python, TypeScript, C++, or Java that would let you capture values of variables and runtime of functions for any number of test cases. The SDKs would submit that information to the our remote server that would compare them against the baseline version, and visualize and report any differences.
If you like to learn more: https://touca.io/docs/basics/ And you can find some product highlights here: https://touca.io/blog/touca-v2/
Like SonarQube?
> If you were to use Touca, you would continue to run "cargo test/npm test/dotnet test/whatever" that are likely running unit tests and integration tests.
My company can barely invest in 80% unit test coverage. We have engineers writing tests to game coverage with no assertions. How is an organization expected to invest in even more time to write another type of test?
No. Instead of linting or static analysis, we tell you when a recent code change is causing your software to behavior or perform differently when handling a particular test case. Like Cypress but for software workflows that don't have a web interface or are not easy to test end-to-end.
> My company can barely invest in 80% unit test coverage. We have engineers writing tests to game coverage with no assertions.
Organizations are already investing in this other type of test by assigning QA teams to write and run manually or using software test automation tools. Touca offers a developer-friendly alternative to these tools that helps orgs save costs. It's a shift-left testing solution that helps engineers get the same confidence that QA teams provide, during the development stage.
From my experience, teams resort to superficial coverage goals because higher-level tests or the test infra needed to continuously run them are too expensive and complicated to run. We wanted to fix that.