Seeing so many different testing frameworks in every programming language. Would love to understand how this happened, when they all seemingly do the same thing. Would love to know which is your favorite and what makes it different than whatever else popular framework in your language?
Pytest is pretty nice, especially when you get it configured with a bunch of plugins for the libraries/framework you're using, and write your own stack of injectors to test your application in different ways. The very lightweight dependency injection is a joy to use once you get used to it. Add in nice output formatting from the built in asserts, and plugins like pytest-randomly that encourage good test writing, and it's really a great setup for almost all Python testing needs. I'd even suggest that it's a great setup for non-Python testing if you want automation around running binaries that you're treating as a black box.
It's been about a year or so now or less for me, but I really enjoyed working with Go's built-in tests. I had not experienced anything else like that before. It was truly incredible to see it as a first-class language CLI feature, but also that it worked alongside your file tree in a designated way.<p>Now, anything less than such functionality is second or third-rate to me. I can give older languages a pass, but anything not having this moving forward is disappointing now.
My context: Backend Java/Kotlin dev. Don't really need any fancy test framework, JUnit 5 is absolutely fine for executing the tests. But I do use a bunch of additional tools and libraries.<p>testcontainers so I can write proper integration tests instead of mocking dependencies away.<p>AssertJ for fancy assertions with great failure messages.<p>Mockito for the rare mocking/spy usage.<p>Awaitility for the rare async/timing based test.<p>When there is a Frontend (templated or SPA, doesn't matter), I like writing the tests with Selenide assertions and using its Selenium integration to run against a large array of browsers + variants (Chrome, FF, Mobile etc) launched via testcontainers.
We built something a bit novel that is focused on composable integration testing in Clojure. We've used this for many years and found it quite useful for keeping a large testing codebase sane.<p>Overview: <a href="https://eng.amperity.com/posts/2019/04/greenlight" rel="nofollow">https://eng.amperity.com/posts/2019/04/greenlight</a>
GitHub: <a href="https://github.com/amperity/greenlight">https://github.com/amperity/greenlight</a>
Not really a framework, but I really like how golang made testing part of the language/stdlib/tooling. Is it perfect? No. Is it pretty good? Yeah.<p>In terms of frameworks, I am a big fan of testify. [0] Unfortunately it doesn't seem like the testify maintainers want to incorporate generics. [1] I'm going to be releasing a library soon to address that.<p>I'm also going to be releasing a golang+python+typescript library for doing super cheap/fast database-backed tests. In my last job I found it incredibly useful, it essentially made it ~0 cost to write tests that exercised database-related codepaths and logic, which for most business apps is everything important.<p>[0] <a href="https://github.com/stretchr/testify">https://github.com/stretchr/testify</a><p>[1] <a href="https://github.com/stretchr/testify/issues/1147">https://github.com/stretchr/testify/issues/1147</a>
<i>Vitest</i> - <a href="https://vitest.dev/" rel="nofollow">https://vitest.dev/</a> - for <i>JavaScript</i><p>I worked with Jasmine and Jest as well, but Vitest was created recently and to me it seems to have made good improvements over both.
I tend to use anything that offers property-testing, since tests are much shorter to write and uncover lots more hidden assumptions.<p>My go-to choices per language are:<p>- Python: Hypothesis <a href="https://hypothesis.readthedocs.io/en/latest" rel="nofollow">https://hypothesis.readthedocs.io/en/latest</a> (also compatible with PyTest)<p>- Scala: ScalaCheck <a href="https://scalacheck.org" rel="nofollow">https://scalacheck.org</a> (also compatible with ScalaTest)<p>- Javascript/Typescript: JSVerify <a href="https://jsverify.github.io" rel="nofollow">https://jsverify.github.io</a><p>- Haskell: LazySmallCheck2012 <a href="https://github.com/UoYCS-plasma/LazySmallCheck2012/blob/master/README.md">https://github.com/UoYCS-plasma/LazySmallCheck2012/blob/mast...</a><p>- When I wrote PHP (over a decade ago) there was no decent property-based test framework, so I cobbled one together <a href="https://github.com/Warbo/php-easycheck">https://github.com/Warbo/php-easycheck</a><p>All of the above use the same basic setup: tests can make universally-quantified statements (e.g. "for all (x: Int), foo(x) == foo(foo(x))"), then the framework checks that statement for a bunch of different inputs.<p>Most property-checking frameworks generate data randomly (with more or less sophistication). The Haskell ecosystem is more interesting:<p>- QuickCheck was one of the first property-testing frameworks, using random genrators.<p>- SmallCheck came later, which enumerates data instead (e.g. testing a Float might use 0, 1, -1, 2, -2, 0.5, -0.5, etc.). That's cute, but QuickCheck tends to exercise more code paths with each input.<p>- LazySmallCheck builds up test data on-demand, using Haskell's pervasive laziness. Tests are run with an error as input: if they pass, we're done; if they fail, we're done; if they trigger the error, they're run again with slightly more-defined inputs. For example, if the input is supposed to be a list, we try again with the two forms of list: empty and "cons" (the arguments to cons are both errors, to begin with). This exercises even more code paths for each input.<p>- LazySmallCheck2012 is a more versatile "update" to LazySmallCheck; in particular, it's able to generate functions.
It's a bit context dependent. Generally prefer tools that allow running multiple tests in parallel because I hate waiting. Unfortunately I'm a few years out of date on JavaScript testing frameworks so I'll abstain from naming specific tools. If it's easy to switch between test frameworks and there's no big differentiating features I would try em all out and use whichever runs fastest.<p>I think Test Anything Protocol [0] [1] is neat. Anything that takes inspiration from TAP is probably gonna be mostly structurally similar anyway.<p>It's easier to point out things I dislike in a testing framework. In general, anything that gets too fancy or magical, or assertion frameworks with lots of object chaining to read like natural language.<p>[0] <a href="https://en.wikipedia.org/wiki/Test_Anything_Protocol" rel="nofollow">https://en.wikipedia.org/wiki/Test_Anything_Protocol</a><p>[1] <a href="https://testanything.org/" rel="nofollow">https://testanything.org/</a>
I'm a fan of RSpec and any BDD (Behavioral Driven Development) type of framework. You are correct that they all do the same thing, but for me everything boils down to which one provides the quickest understanding of the code by the reader.<p>There's another testing library in Ruby that is called minitest. The syntax is different, for example you would write "assert_equal num1, numb2". My problem with this is that you don't know which is the expected vs the actual values. Is it the first or second argument? On the otherhand, my framework of choice, RSpec would write this as "expect(num1).to eq(numb2)". The syntactic sugar alone makes this easier to understand.
Definitely Jest, I've tried few in the past and one of the great things of Jest is how easy it is to extend and customize if you are a library author with meaningful messages.<p>So I wrote a small test runner for React (`react-test`) and added few custom Jest matchers, so you can do:<p><pre><code> const button = $(<Button>Hello World</Button>);
expect(button).toHaveClass('btn');
expect(button).toHaveText('Hello World');</code></pre>
My favorite was the SUnitToo package for VisualWorks Smalltalk. It was integrated right into the IDE. The code browser was a natural fit for really intuitive feedback for running tests and getting feedback.<p>The Smalltalk language and SUnit library had a really great signal ratio without a lot of boilerplate that goes with a lot of other xTest frameworks.<p>Shameless plug — I was the author of said tool.
I generally like rspec because:<p>* The setup pattern with "just in time" variables is amazing.<p>* It offers some _extremely_ terse tests<p>* It offers a huge library of plugins.
The API and output on failure from Perl's Test2-Suite (<a href="https://metacpan.org/dist/Test2-Suite" rel="nofollow">https://metacpan.org/dist/Test2-Suite</a>) is amazing. I miss it in every other language I work in, especially Go and Rust, both of which have fairly anemic tooling for this stuff compared to Perl.<p>I've tried making something similar in Go (<a href="https://pkg.go.dev/github.com/houseabsolute/detest/pkg/detest" rel="nofollow">https://pkg.go.dev/github.com/houseabsolute/detest/pkg/detes...</a>) but the language makes having as nice an API impossible, and I really don't love what I've come up with there. The output from detest is pretty nice though (until it wraps lines in which case it's a mess).
Haskell’s Tasty framework.<p>It lets me combine HSpec for unit tests and Hedgehog for property tests in the same test files with test auto-discover. For failed properties, it prints the seed.<p>And it has really pretty, readable output.<p>I’m using Rust’s tests currently, and the output is just a lot less obvious. E.g. green text when 0 tests are run.
> Seeing so many different testing frameworks in every programming language. Would love to understand how this happened,<p>Asking everyone for their favorites is not likely to meet that goal.<p>> when they all seemingly do the same thing<p>You haven't actually looked into this at all before asking, have you?
I write mainly HTTP APIs and I almost exclusively test them with a lesser known tool: Venom[1]<p>(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)<p>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.<p>A very basic HTTP API test would look like this:<p><pre><code> - type: http
method: GET
url: http://localhost:8080/ping
assertions:
- result.statuscode ShouldEqual 200
- result.bodyjson.status ShouldEqual ok
</code></pre>
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:<p><pre><code> - type: sql
driver: postgres
dsn: xxx
commands:
- SELECT * FROM table
assertions:
- result.queries.queries0.rows ShouldHaveLength 8
</code></pre>
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.<p>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.<p>[1]: <a href="https://github.com/ovh/venom">https://github.com/ovh/venom</a>
I like Rust unit tests, simply because you don't need to set anything up to use them. Also they can go in the module you're testing, so writing tests for things that are not public is simple.
I’ve found the datadriven[1] testing approach in go to be quite effective. The idea is that you leverage a standardized file structure to construct a little DSL for testing your code. This allows you to write expressive tests that print the state of the code and then look at it. Rewrite is also very powerful.<p>This is all inspired by the sqllite logic test framework.<p>[1]: <a href="https://github.com/cockroachdb/datadriven">https://github.com/cockroachdb/datadriven</a>
In my opinion it is Spock for Java/Groovy [1]. The amount of functionality and readability you can squeeze from Groovy's DSLesque is absurd. Is basically a full fledged new test language with Java sprinkled as the test contents code<p>[1]: <a href="https://spockframework.org/" rel="nofollow">https://spockframework.org/</a>
For Scala, Specs 2. Just overall well designed, useful, yet flexible API.<p>I'm looking for something for Node.js. I've used jest, but it's very heavy and does all sorts of magic and is a whole build system. Whereas I just want a test runner with utilities and reporting.
I'm liking catch2 for cpp tests these days.<p>It is easy to have an idea for a testing framework that you can quickly write yourself. That is why there are so many. It is tedious to add all the features people want so many are not quite as good as their hype.
pytest. The way it handles both fixtures and parameterization (and the fact that it doesn't force classes on me) genuinely results in me enjoying writing tests.<p>I'd love to find a JavaScript testing framework that's as pleasant to work with.<p>I wrote a bit about those two features here: <a href="https://simonwillison.net/2018/Jul/28/documentation-unit-tests/" rel="nofollow">https://simonwillison.net/2018/Jul/28/documentation-unit-tes...</a> - about half way down.
<i>> ...Would love to understand how this happened...</i><p>Well, why are we using cut-down Chrome with a bunch of js scripts and pretend it's a native app or a web server?
I’ve worked on countless codebases with thousands of unit tests, integration tests, synthetic tests, automated acceptance tests, automated UI tests, etc.<p>The only real “test” is whether it works in production. Everything else is a poor substitute and gives you false confidence. It’s absurd the amount of time and effort we spend on writing tests and we still have as many, if not more bugs in our software than we did before writing tests became a religion.
ospec is king in JS land. Ultra small, does what I need, gets out of the way and doesn't come with any corny grammar.<p><a href="https://github.com/MithrilJS/ospec">https://github.com/MithrilJS/ospec</a>
Outside of differences between assertion-based unit tests and property-based tests (both of which are worth doing), I don't think framework makes much difference. But your approach to testing definitely does.<p>I think every language having its own testing framework is good, even for things like functional tests which can often be externalised. Tests are an essential part of every project and should be well integrated with the rest of the codebase and the team creating it. Often, the tests are the only good place to go and see what an app actually _does_ and so they form an essential part of the documentation.<p>In my experience it's very rare that you can effectively create and maintain something like Cucumber tests owned by anyone but the team implementing the code so there's little benefit to translating from a text DSL like that. But the language used is definitely useful, so what I like to see is code in the implementation language that matches the Given/When/Then structure of those tests, but instead of reusable text steps you just have reusable functions which take parameters. This means you can easily refactor, and use the full functionality of your IDE to suggest and go to definitions etc. No matter what, you should treat your test code the same way you do everything else - abstractions matter, so functional tests at the top level should rarely just be about clicking on things and asserting other things, they should be in the language of the domain.<p>Functional tests are worth much more than unit tests. No only do they test the only things of actual business value, they are also more robust in the face of implementation refactorings and so require less rework (unless you're being overly specific with CSS selectors etc). Unit tests are often highly coupled to specific implementations and can be a poor investment, especially early in a project. I believe a good balance is functional and integration tests that explore the various paths through your app and prove everything's hooked up, coupled with property based unit tests for gnarly or repetitive logic that isn't worth endlessly iterating via the UI. All other unit tests are optional and at the discretion of the implementer.<p>You should be able to mock out every major articulation point in your code, but it's generally preferable if you can mock _real_ dependencies. That is, instead of mocking out a 'repository' abstraction that looks stuff up and returns canned data, have a real test database against which you look up real data (created by steps in your functional tests). This reduces risk and cognitive overhead (you're not having to encode too many assumptions in your test suite) and doesn't have to be as slow as people like to make out - Embedded Postgres is quite fast, for example:<p><a href="https://github.com/zonkyio/embedded-postgres">https://github.com/zonkyio/embedded-postgres</a><p>Same with network services - it's not slow to chat to localhost and you'll find more issues testing proper round-trips. I have not found "assert that you called X" style testing with mocks useful - you care about outcomes, not implementation details.<p>Beyond all that, as long as you can make assertions that generate clear error messages, you're fine.