Re:Launch HN: Codeparrot (YC W23) – Automated API testing us...
by Aeolun on Friday March 17, 2023 @05:47PM
(#35203349)
I think the fact they use opentelemetry figures into this. They’ve already done the hard work of intercepting calls to many libraries.
Re:Launch HN: Codeparrot (YC W23) – Automated API testing us...
by royal0203 on Friday March 17, 2023 @06:41PM
(#35203860)
Yes, we rely a lot on openTelemetry for this. They have really good support for most libraries in Java, node and are progressing quickly in others. We are also contributing to it by extending support for other languages, which we'll be open sourcing soon.
Re:Launch HN: Codeparrot (YC W23) – Automated API testing us...
by Aeolun on Friday March 17, 2023 @08:38PM
(#35204788)
If you are contributing, isn’t it open-source by default? Or you mean you have ‘proprietary-ish’ (since it’s all client side, kind of impossible) packages that aren’t part of opentelemetry yet?
Re:Launch HN: Codeparrot (YC W23) – Automated API testing us...
by royal0203 on Saturday March 18, 2023 @03:48PM
(#35212457)
Yes, I meant packages not part of opentelemetry - example python has lot of DB packages which don’t have support yet.
Re:Launch HN: Codeparrot (YC W23) – Automated API testing us...
by nfw2 on Friday March 17, 2023 @09:09PM
(#35204993)
Does opentelemetry also support mocking outgoing requests values on replay? Or is something else used for that part?
Re:Launch HN: Codeparrot (YC W23) – Automated API testing us...
by royal0203 on Saturday March 18, 2023 @03:49PM
(#35212463)
No, it doesn’t have by default but can be extended to support it.
Re:Launch HN: Codeparrot (YC W23) – Automated API testing us...
by pcthrowaway on Friday March 17, 2023 @09:38PM
(#35205185)
> For example, suppose a startup has an Express app that made downstream requests to Postgres, Redis, Kafka, other REST APIs, etc
And besides network calls network-bound requests, what about reading from sqlite, files, and interprocess communication.
What about ZeroMQ over UDP? A remote time service. Pulling from a git repo.
No really, I'm asking because I'm trying to figure out how to deal with all this in my tests right now, and I honestly have no idea. But I doubt Codeparrot is going to be able to intercept and intelligently mock everything.
Re:Launch HN: Codeparrot (YC W23) – Automated API testing us...
by vedant_ag on Saturday March 18, 2023 @10:08PM
(#35215283)
> What about ZeroMQ over UDP? A remote time service. Pulling from a git repo.
>
> No really, I'm asking because I'm trying to figure out how to deal with all this in my tests right now, and I honestly have no idea. But I doubt Codeparrot is going to be able to intercept and intelligently mock everything.
In theory, *everything* can be recorded and replayed; that's the magic of patching-in at the application layer. *Any* function call can be recorded, and, replayed.
In practice, we support whatever is demanded by our customers. If people are ready to pay for something, we are happy to build support for it.
For example, suppose a startup has an Express app that made downstream requests to Postgres, Redis, Kafka, other REST APIs, etc. How do the outgoing requests, which may follow different protocols, with varying serialization formats and handshakes, all get intercepted, recorded, and matched to the same outgoing calls when the session is replayed? How are the outgoing requests indexed and evaluated for sameness when replayed?
It definitely seems possible to implement something like this as a series of high-level one-off integrations, for example, a middleware package for Django apps. But if the goal is a universal and automatic downstream service mocking system, it's not clear to me where this sort of middleware would even sit in the application stack. It seems like it would need to be pretty low-level, but not too low-level because the needs to be decrypted first.
Anyway, if you guys have figured out a good way to do this, I'm definitely interested in hearing how you managed it. I'm in no way a great BE engineer, so there could be something elegant or obvious that I missed.