Can you elaborate? Most of Clojure libraries I use have extensive, sometimes seemingly too many, tests that accompany them, as if they are covering literally every possible scenario the user could find themselves in.
Sadly, one must investigate original sources, otherwise we get soundbite-knowledge. Here's a blogpost written by a core Clojure contributor that starts: "Occasionally I hear someone say that the Clojure community is against testing." (http://tech.puredanger.com/2013/08/31/clojure-and-testing/)
Or take this discussion on testing: "Finally, testing is greatly facilitated by design. Ideal testing takes some design constraints, some specification and turns it into tests as opposed to sort of embodying design inside tests. That's inside out. But again, that's something we have to work more at. Stems like Quick Check are interesting because you're basically starting with propositions about your system, which reflect the design and saying you write the tests, computer." (https://github.com/matthiasn/talk-transcripts/blob/master/Hi...)
The Clojure community is very big on testing, but not all of it is automated (eg testing on the REPL). Automated testing is popular too though, to the point where Clojure has a number of testing libraries (clojure.test, test.check, test.generative, expectations, speclj, midje).
Sure it does. It depends on the purpose of your tests and the cost/benefit.
Do you really think that just because you have automated tests, that your software is defect free? Tests (outside of generative/property-based testing, which is still under-utilised) aren't very good at finding bugs outside of regressions. Having said that, most Clojure code worth talking about does have automated tests.
In my ideal world, I would use expected-case Unit Tests to test the contract/requirements/interface. Regression tests to prevent fixed bugs from reappearing and generative tests to try and find bugs. I would write the expected-case tests before the code, use REPL testing while developing and finally write property tests after (once my code has evolved so that I understand the properties) and regression tests only as I fix bugs after the fact.
We made heavy use of Primastic's schema when we felt we needed guarantees about the shape of the data, this help in areas where you want the extra checking and documentation.
In practice refactorings such as changing Address->MaybeAddress didn't hurt us so much. With good test coverage also, it's not a huge issue.
Clojure code-bases tend to be more much concise and well organised, so refactoring based on expected data and output doesn't bite as much as people often fear.
