No post body was provided.
Launch HN: Meticulous (YC S21) – Catch JavaScript errors before they hit prod
31–40 of 42 posts
Re: Launch HN: Meticulous (YC S21) – Catch JavaScript errors before they hit prod
#32Pretty slick! I wish we had this a long time ago. At the time, our testing infrastructure was a bunch of very flaky Selenium tests that we would run on through SauceLabs. The tests were super slow, mainly because we tried to reduce flakiness by buffering clicks/interactions with sleep() commands. All around, a painful experience which developers hated, which meant engineers did everything they could to avoid adding/m…
> we tried to reduce flakiness by buffering clicks/interactions with sleep()...
You should have used waits instead of sleep. Wait pools until your DOM is in the state you are waiting it to be, unless given timeout occurs: https://www.selenium.dev/documentation/webdriver/waits/#expl...
Re: Launch HN: Meticulous (YC S21) – Catch JavaScript errors before they hit prod
#33Pretty slick! I wish we had this a long time ago. At the time, our testing infrastructure was a bunch of very flaky Selenium tests that we would run on through SauceLabs. The tests were super slow, mainly because we tried to reduce flakiness by buffering clicks/interactions with sleep() commands. All around, a painful experience which developers hated, which meant engineers did everything they could to avoid adding/m…
Ouch, that does sound like a painful cycle. It happens, and no one tests as much as they'd like to. > Portability of the data. I hear your concern here. The replay data and session data is also saved to disk, so you can save this somewhere. Of course that still leaves the risk of the record & replay tech. I think open sourcing this would solve the portability issue here, and it's something we're actively talking abou…
I worked at a couple of dev tool startups that required you to invest some effort to adopt and would require effort to move away from (e.g. if the company went under) - open sourcing ended up being basically a necessity to sell the product (enterprise sales during seed and A). YMMV, but I would definitely encourage open sourcing enough to make potential adopters feel comfortable that they won't have to do a big, urgent migration and/or lose a bunch of engineering investment if you go under or decide to pivot.
Re: Launch HN: Meticulous (YC S21) – Catch JavaScript errors before they hit prod
#34Hi Gabriel, congratulations for the launch!
I think software development is due for a disruption and your take on testing is spot on.
As part of a dev tool belt we developing, we are building a tool to translate user interaction into a selenium script, and have the selenium script run on our server. User get to take away the script so they don't get vendor lock-in. What is your approach into replaying a user session?
On a broader picture, I think what you do has potential beyond QA. e.g. if run on production, have CS hop on the same session as a troubled user.
Just checked your profile. It seems we both are based in london. Maybe we can grab a beer to discuss the potential.
Re: Launch HN: Meticulous (YC S21) – Catch JavaScript errors before they hit prod
#35When talking about "capturing network traffick", does that include SSE and WebSockets? If used for regression testing, how do you go about updating existing recordings?
It does not include SSE or WebSockets. With regards to updating existing records, unfortunately we don't currently have good tooling & support for this, so you may need to record new sets of sessions as your application changes. I would suggest starting off with testing a few core flows.
Thanks for clarifying. The value proposition of automatic request/response recording brings something genuinely new to the area, but without a WS support, not all projects could benefit completely.
This reminds me of the test suite for one of my projects where E2E tests only covered relatively simple scenarios because of subpar WS mocking support, leaving more important, complex interactions to manual (can't run in CI) or fully integrated (expensive to author and run often) testing. The situation changed only after we wrote a custom WS mocking layer over the HTTP mocking the framework provides, yielding a dramatic increase in coverage. Out of dozens of developers I interviewed, only a few solved this issue to some degree. Clearly, mainstream testing frameworks provide insufficient support for the use case.
Re: Launch HN: Meticulous (YC S21) – Catch JavaScript errors before they hit prod
#36Evaluating technologies by analogy, how far off base am I?
jQuery, Angular, React
are analogous to:
Selenium, Puppeteer, Playwright
Is Selenium still worth considering for a brand new project, though primarily due to ecosystem instead of implementation (Ruby, IDE, etc.)?
To frame the question in context of the analogy, though now completely off-topic:
What is the React equivalent of datatables.net?
Re: Launch HN: Meticulous (YC S21) – Catch JavaScript errors before they hit prod
#37Earlier quoted context omitted.
It does not include SSE or WebSockets. With regards to updating existing records, unfortunately we don't currently have good tooling & support for this, so you may need to record new sets of sessions as your application changes. I would suggest starting off with testing a few core flows.
Thanks for clarifying. The value proposition of automatic request/response recording brings something genuinely new to the area, but without a WS support, not all projects could benefit completely. This reminds me of the test suite for one of my projects where E2E tests only covered relatively simple scenarios because of subpar WS mocking support, leaving more important, complex interactions to manual (can't run in C…
I agree that WS replay could be very powerful, but I'm not sure it's straightforward. Once you get out of the realm of request/response and you are dealing with subscriptions, connection multiplexing, or frankly any other sort of pushed data that is triggered by whatever is on the other end, knowing how and when to play that back against new sessions is very hard. It seems very application specific on face value.
But I agree that it would enable replay for a lot of very interesting, complex projects. I've worked on some FX trading UIs that have been challenging to test without standing up a lot of backend services.
Re: Launch HN: Meticulous (YC S21) – Catch JavaScript errors before they hit prod
#38Congrats on the launch.
How do you deal with generating resilient selectors automatically? That's a class of problem which plagues this type of tool in my understanding.
Re: Launch HN: Meticulous (YC S21) – Catch JavaScript errors before they hit prod
#39How does it differ from ages old selenium and it’s browser plug-in to record tests? Afaik the worst bit is the indeterminism introduced by network waits, etc that makes e2e complicated and often not worth its upkeep.
Re: Launch HN: Meticulous (YC S21) – Catch JavaScript errors before they hit prod
#40Congrats on the launch. How do you deal with generating resilient selectors automatically? That's a class of problem which plagues this type of tool in my understanding.
Would to love to know this too. Would it fare well against a very interactive desktop-like web app that may not be built everywhere to be testable. We use selenium but it is always a trade off due to natural flakiness if web testing.
My other concern is I would want it to be open source and self hostable. That runs against being commercial though but serious companies will pay a licence for support. If not then a solid promise that the company phoenixes to open source if it shuts down, and allows closed source self hosting while open.