JIjicea·Feb 25, 2026Submission
Venom, run integration tests with efficiency
1 points · Open discussionovh
venom
Go2022–2026
ovh / venom
venom
🐍 Manage and run your integration tests with efficiency - Venom run executors (script, HTTP Request, web, imap, etc... ) and assertions
6Distinct people
8Mentions
0Explicit recommenders
1.2KGitHub stars
What to know before exploring
What it is
🐍 Manage and run your integration tests with efficiency - Venom run executors (script, HTTP Request, web, imap, etc... ) and assertions
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year8 dated mentions
Observed mentions: 2022-03-21 14:01:37 UTC to 2026-02-25 20:36:54 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
8 sourcesI'm working on pact[0], a tool to enable developers and hopefully less technical users to interact with Playwright and perform actions and tests on web-based user interfaces and applications using either a YAML file or a simple DSL (in a .pact file).
Initially this started off as a feature for a PR on venom[1], an integration testing tool, but as I thought about it more - it made sense to maybe make a standalone tool that can evolve a bit different from venom. It's still very early but it works to perform some basic actions using typical CSS selectors that playwright supports.
[0]: https://github.com/zikani03/pact
[1]: https://github.com/ovh/venom
In Ask HN: What are you working on? (July 2025)Yeah I didn’t came up with the idea first, at my work we used an in house solution[1] but it had lots of shortcomings (hard to read output, hard to debug tests, virtually no documentation, and the code was very hard to extend and fix). My plan is to fix all these issues and more :)
[1]: https://github.com/ovh/venom
In Ask HN: What are you working on (August 2024)?I write mainly HTTP APIs and I almost exclusively test them with a lesser known tool: Venom[1]
(For the background, I used to work at OVHcloud and Venom was developed by the core/platform tool. I'm usually not a big fan of in-house tooling when I can avoid it, but I found Venom's paradigm so good that I still use it to this day and can't imagine not using it to test my APIs now)
It's an integration testing tool in which test suites are written declaratively in YAML. It's completely language agnostic, and you can be 100% sure you're actually testing behaviors and contracts. This was once very useful to us as we migrated an old Python API to Go, with the same interface contract. We just kept the same test suites, with pretty much no changes.
A very basic HTTP API test would look like this:
- type: http
method: GET
url: http:
Read the rest
//localhost:8080/ping
assertions:
- result.statuscode ShouldEqual 200
- result.bodyjson.status ShouldEqual ok
But where it shines in my opinion is that you can not only make HTTP calls, but also database calls. So when you implement and test a DELETE endpoint, you can also make a query to check you didn't delete ALL the database:
- type: sql
driver: postgres
dsn: xxx
commands:
- SELECT * FROM table
assertions:
- result.queries.queries0.rows ShouldHaveLength 8
You can also load fixtures in database directly, work with Kafka or AMQP queues both as a producer (e.g. write an event to a Kafka queue, wait a few seconds and see that it was consumed by the service you test, and that some side effects can be observed) or as a consumer (e.g. make sure after an HTTP call, an event was correctly pushed to a queue), or even read a mailbox in IMAP to check that your service correctly send an email.
It's a bit rough on the edges sometimes, but I'd never go back on writing integration tests directly in my programming language. Declarative is the way to go.
[1]: https://github.com/ovh/venom
From my experience, generated tests are worthless for anything more serious than smoke tests. I prefer working with no tests than automated tests, I feel they give you a false sense of confidence.
The Step CI engine itself looks good though. It looks like a cleaner, but less powerful version of a tool (open source, build in-house) we used when I worked at OVHcloud, Venom: https://github.com/ovh/venom
Here's an example test file for the HTTP executor of Venom: https://github.com/ovh/venom/blob/master/tests/http.yml it's very close to Step CI format.
I'd still use Venom because it's way more powerful (you have DB executors for example, so after executing a POST request you can actually check in DB that you have what you expect) and I prefer focusing on actually writing integration tests instead of generating them.
Maybe this post sounds har
Read the rest
sh (I feel it as I write it because I have strong feelings against test generation) but I think your approach is a good one for actually writing automated tests. Testing APIs declaratively like this has a great benefit: your tests work on an interface. You can migrate your API to a whole new stack and your tests remain the same. I did it multiple time at OVHcloud: one time migrating a huge API from a Go router to another (Gin->Echo), and another time migrating public APIs from a legacy, in-house Perl engine to a Go server.
Venom: Manage and run your integration tests with efficiency
2 points · Open discussionIf you are looking for a more general tool, which can do not only API tests, but also interact with Databases and etc, but still use declrative syntax, try Venom https://github.com/ovh/venom
In Show HN: We built a tool that automatically generates API testsI still struggle with GDB but my excuse is that I seldom use it.
When I was studying reverse engineering though, I came across a really cool kit (which I've yet to find an alternative for lldb, which would be nice given: rust)
I'd recommend checking it out, if for no other reason than it makes a lot of things really obvious (like watching what value lives in which register).
https://github.com/hugsy/gef
LLDB's closest alternative to this is called Venom, but it's not the same at all. https://github.com/ovh/venom
In Debugging with GDB