Approaches to unit testing

practicalli:speech_bubble: 13:24
@dharrigan I am not subscribed to the idea that every function must be unit tested driectly, especially if this slows down the feedback you get from tests (or stops the team running tests so often).Every function should be tested of course and any public API to your code should be tested rigorously (ideally generative testing). Private functions are often very small and generic helper functions, used by many other functions. Those helper functions are therefore tested extensively by the unit and integration tests of the public functions. If I did write direct unit tests for all functions, I would invest more in the design of those that test public functions and less in those tests for helper functions.After all unit tests require maintenance. However, I do think it is a lot less maintenance in Clojure to write unit tests for absolutely every function. Many languages struggle with the amount of unit tests over time. Following the typical modular approach in Clojure design and the more terse nature of the code, excessive amounts of tests.Organising your tests into categories is very effective, so only subsections of tests are run. This is especially so when you have integration and performance tests and the larger the codebase you have.

guy 13:31
How do you balance out generative testing with time taken by the tests?
13:31
I've always found they add a signifcant overhead time wise (couple mins) vs unit tests
13:32
Or do you just not run them that often?
13:35
ah just reread what you said
practicalli:speech_bubble: 13:35
If you can group together generative tests, then you can get your CI to run then and just run unit tests as a dev profile. There is plenty of opportunity to run generative tests locally, eg. just before a meeting, comfort break, getting a glass of water, lunch, etc.

No files, tests, or entry points are named; start by identifying where this repository documents its testing approach and how unit, integration, and generative tests are grouped or invoked. Done would require an agreed testing policy and corresponding documentation, but the issue does not define a specific document or change.