pejman_gh

Thank you.

Not doing so was certainly one of my execution mistakes. It makes a ton of difference in how you execute and the knowledge that you are being compensated for the work may have helped protect my mental health.

Thank you. First time in 2 years that I actually purchased a book recommendation and am optimistic to read it through. Under-appreciated perks of having a life again. :)

> Like SonarQube?

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.

I think that's in Portuguese? Touca is also the name of a bird (Toucan) in Farsi.

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. :)

Thank you!

Founder and author here. Yes, while there were other external factors beyond our control, e.g. bad market, I think we failed primarily because our product was a nice-to-have and easy for customers to justify not paying for.

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...

I agree GitHub Actions job summary does not take the place of a GitHub App. The latter is part of our Q1 roadmap.

Reviewing diffs using `git diff` or `git blame` is not part of our roadmap. In fact we want to replace that model so that we can provide more insights and better summaries than just showing the diff between two textual outputs. Currently, you can use the Touca CLI to capture test results and get feedback whether they are any different. But you'd need to use our web interface to see and manage the comparison results in details. We're working to expand the CLI so that you could see the diff between any two versions right in the terminal.

Glad to hear. Yes, your understanding is very accurate. TDD requires a different mindset. Our primary focus has been do a great job of finding side effects of code changes to existing systems such as day-to-day refactors and occasional rewrites. From my personal experience, these are the scenarios in which having hard-coded expected values in assertions is inconvenient and requires mechanical adjustments. Thanks for taking the time to review this and sharing your thoughts.

Unless a special command-line flag is provided, the test runners return a success exit status. Since we don't know whether potential differences are intended, we don't want to fail the CI by default. When differences in a given version are expected, you can promote that version as the new baseline through the web interface. This way, the test results for all subsequent versions will automatically be compared against the new version.