3 ms·
Just to intensify the sacrilege here: I’ve been happy testing private behaviour with tests directly alongside the code. This way you can easily sweep away the t
by thom 3y ago
Just to intensify the sacrilege here: I’ve been happy testing private behaviour with tests directly alongside the code. This way you can easily sweep away the test code if you change the implementation, and it serves as decent documentation for complex implementation details. The tests obviously disappear in production builds either way.
- JohnBooty 3y agoI’ve been happy testing private behaviour with tests directly alongside the code. I'm intrigued but I don't understand. What does this look like? What language is this?
- thom 3y agoIn Clojure, for example, tests are defined by a macro that decorates a function with certain metadata marking it as a unit test. So they can live and be run from anywhere, but get stripped out of proper builds. You can also go one further, and wrap a function definition in a `with-test` block, so any assertions you make against the function are kept directly alongside its definition, which is a nice form of documentation. What this means is that you can have tests for implementation details, that are cordoned off from your main test suite (which defines your code's real requirements and public API). The benefit is that if you change implementations and suddenly a function is no longer needed, you can just delete the test code right there in the same file, so refactoring is very slightly easier and more obvious. You can also decide whether they should be run during your build process or just at dev time.
- JohnBooty 3y agoThat's interesting, thank you!