So I realized what I value more than the quality of the tests and documentation is that I want somebody to have _used_ the thing.

So I realized what I value more than the quality of the tests and documentation is that I want somebody to have _used_ the thing. If you've got a vibe coded thing which you have used every day for the past two weeks, that's much more valuable to me than something that you've just spat out and hardly even exercised.

Most passing SWE-Bench solutions are not accepted by maintainers.

This class of bug is insidious because it evades every layer of defense. It will not be caught in development testing — who runs a test for 50 days? It will not be flagged in code review — the logic looks perfectly reasonable.

This is the most simulative version of a controller. It will try and mimic real user behaviour. It's the recommended version to use when the goal of the load-test is finding out how many concurrently active users the target instance supports.

As of right now the full build takes over an hour to run, and this makes cycling for PRs and quick iterative development very difficult.

the functional core, imperative shell pattern

For new code, it’s usually a good idea to design the code so that it’s easy to test with “real” objects, rather than stubs or mocks.

We keep our functional tests separate from our unit tests, in the tests/functional directory. Because these are slow to run, we will usually write one or two functional tests to check a new feature works in the common case, and unit tests for all the other cases.

To run the backend test suite only call tox directly

Black Box testing: Software on the rack

A test case is a series of actions that are performed to determine a specific function or functionality of your application. Test scenarios are rather vague and include a wide range of variables. However, testing is all about being very specific. That is why we need elaborate test cases.

I am firmly convinced that asserting on the state of the interface is in every way superior to asserting on the state of your model objects in a full-stack test.

The more your tests resemble the way your software is used, the more confidence they can give you.

This is why for a recent Angular+Rails project we chose to use a testing stack from the backend technology’s ecosystem for e2e testing.

There are times to stretch individually and as a team, but there are also times to take advantage of what you already know.

targeting what the user actually sees

The most important guideline to give is the following: Write clean unit tests if there is actual value in testing a complex piece of logic in isolation to prevent it from breaking in the future Otherwise, try to write your specs as close to the user’s flow as possible

It’s better to test a component in the way the user interacts with it: checking the rendered template.

There’s no need to test controllers, models, service objects, etc. in isolation

Run the complete unit with a certain input set, and test the side-effects. This differs to the Rails Way™ testing style, where smaller units of code, such as a specific validation or a callback, are tested in complete isolation. While that might look tempting and clean, it will create a test environment that is not identical to what happens in production.

Library author here. I'm always fascinated by new ways people can invalidate my assumptions. I mean that in a sincerely positive way, as it results in learning.

development is hard because you have to preserve the ability to quickly improve the product in the future

It is also good practice to make sure that your load testing is functionally correct. Both the performance and functional goals can be codified using thresholds and checks (like asserts).

"The more your tests resemble the way your software is used, the more confidence they can give you. "

You want to write maintainable tests for your React components. As a part of this goal, you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended. As part of this, you want your testbase to be maintainable in the long run so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

We try to only expose methods and utilities that encourage you to write tests that closely resemble how your web pages are used.

The more your tests resemble the way your software is used, the more confidence they can give you.

Most of the damaging features have to do with encouraging testing implementation details. Primarily, these are shallow rendering, APIs which allow selecting rendered elements by component constructors, and APIs which allow you to get and interact with component instances (and their state/properties) (most of enzyme's wrapper APIs allow this).

This library is a replacement for Enzyme.

Here are my tools of choice for testing React apps:react-test-renderer for snapshot unit testingAct API for unit testing React componentsJest for unit and integration testing of JavaScript codeCypress for end to end / ui testing

Something that I've found helps greatly with testing is that when you have code with lots of nested function calls you should try to refactor it into a flat, top level pipeline rather than a calling each function from inside its parent function. Luckily in clojure this is really easy to do with macros like -> and friends, and once you start embracing this approach you can enter a whole new world of transducers. What I mean by a top level pipeline is that for example instead of writing code like this: (defn remap-keys [data] ...some logic...) (defn process-data [data] (remap-keys (flatten data))) (defn get-data [] (let [data (http/get *url*)] (process-data data))) you should make each step its own pure function which receives and returns data, and join them all together at the top with a threading macro: (defn fetch-data [url] (http/get url)) (defn process-data [data] (flatten data)) (defn remap-keys [data] ...some logic...) (defn get-data [] (-> *url* fetch-data process-data remap-keys)) You code hasn't really changed, but now each function can be tested completely independently of the others, because each one is a pure data transform with no internal calls to any of your other functions. You can use the repl to run each step one at a time and in doing so also capture some mock data to use for your tests! Additionally you could make an e2e tests pipeline which runs the same code as get-data but just starts with a different URL, however I would not advise doing this in most cases, and prefer to pass it as a parameter (or at least dynamic var) when feasible.

You shouldn’t really be doing this anyway – you should have composed them, possibly via IOC.