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

Touca (github.com/trytouca/trytouca) gives fast feedback (via email or PR comment) for each PR you create that shows you how the behavior and performance of your software has changed compared to a previous trusted version.

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/

I admit it's always been a point of struggle for me as a technical solo first-time founder. We should have done a better job with messaging too.

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.

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

Hello! Sorry for the confusion. What we mean is that, unlike unit testing, the test inputs are not tightly coupled with the test code and you can write a single block of test code and have it executed for any number of inputs.

The example in Readme is passing the inputs as a list. You could also use a lambda function (see https://touca.io/docs/sdk/testcases/#programmatic-testcase-d...). Alternatively, you can remove the list and pass the inputs as command-line arguments. You can even choose not to pass them at all, in which case the test runner will re-use the list of test cases in the baseline version.

Hi Andrew, to clarify, we do support generating local snapshot files in either JSON or Binary with FlatBuffers format (see https://touca.io/docs/sdk/capturing/#locally-storing-test-re...). We also provide `touca results` which helps with managing binary result files (see https://touca.io/docs/cli/results/). So it is possible to forgo the Touca server and just use the SDKs to capture values of interesting variables or runtime of important functions.

Storing test results in Git and comparing them via external tools may make it easier for teams to get started with Touca. But we care a lot about the developer experience and think that having a remote server take care of storage, comparison, visualization, and reporting could make a lot of sense for teams building serious software.

Touca has several components that work great together but you can certainly pick and choose and don't have to use all of them. We like Touca to do as much work as possible including integration with CI so that tests run continuously. But that integration is also optional. If teams have a different CI than GitHub Actions, they could call `touca test` as a CI step instead of using our plugins.

Does my explanation address your concern?

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.

Hi there, maker of Touca here. Thanks for sharing your thoughts! Being able to visualize the differences along side pull requests is helpful. We currently provide that insight for each commit using Github Actions job summary and plan to add a GitHub App in the future to report differences as a PR comment. Touca also allows locally storing the captured data points for users who like to do so . We argue that visualizing the differences shouldn't require storing snapshot files in version control because 1. they are inconvenient to maintain 2. what you can store in them is limited to what your application produces as output. I've written a bit about this in our docs here: https://touca.io/docs/guides/vs-snapshot/ Would really appreciate hearing if you find this argument reasonable.

Hi everyone, Touca is an open-source continuous regression testing system that helps engineering teams get faster feedback on the potential side-effects of their day to day code changes. We're a fully-remote team of four, fresh out of Techstars, and in the process of raising our first round of funding.

We want to remove testing as the bottleneck in software development. On average, it takes engineering teams 23 days to gain confidence whether their code changes work as they expect. Touca reduces this long feedback cycle to a few minutes to give feedback to engineers when they write code that could break their software.

We're looking for someone who could help us tell our story while wearing many other hats. We're calling it "Head of Marketing" but this position is a great opportunity to define your own career path and grow into your ideal role.

You may be a technical person with some marketing experience who is thinking about becoming a developer advocate. Or you may be someone with prior work experience at a high-growth startup who is thinking about making a career in marketing or operations. As long as you are ambitious, autonomous, and results-driven, we want to speak with you. Join us! Let's make building software 10x more efficient.

Hi folks, I'm Pejman, founder of Touca, a developer-friendly regression testing system that provides feedback to software engineers when they write code that could break their software. I started Touca as a side-project and an internal tool at my previous employer until last years when I left my job to grow it as a business. In the past year, we were focused on offering Touca to enterprise companies, thinking that they would find it the most useful. While our thinking was right, our growth was very slow, so last month, we decided to fundamentally change our go-to-market strategy and rethink every aspect of Touca as a business. As part of that change, we open-sourced Touca last month under the permissive Apache-2.0 license, and changed our business model to charging for our cloud services.

See: https://touca.io/blog/open-source-announcement/

But in our industry, the word open-source has occasionally been misused as a marketing ploy. Restrictive licenses, incomplete offerings, forced upgrades... I think there's more to becoming an open-source company than letting people see your source code. I tried last night to outline my thinking on this subject and the efforts we are going to make at Touca to earn this title. I'd love to hear your thoughts and hope that you find this post worthwhile.

Hello. Pejman here from Touca.

Touca helps developers see the true impact of their code changes on their overall software, as they write code. Our open-source SDKs enable engineers to describe the behavior and performance of their code by capturing values of interesting variables and runtime of important functions. We remotely compare their description against a trusted version of their software and visualize any differences in near real-time.

We released our SDK for Node.js recently. You can find it on GitHub at https://github.com/trytouca/touca-js. I'd love for you to check it out and share what you think about it and about our new approach to testing complex software workflows.