Hacker News Reader

Comment by pka | Hacker News Reader

How did you handle refactorings? Like, changing userAddress's "type" from Address to Maybe Address?

This is what scares me the most in Clojure and all other dynamic languages - that early on in the project, I'd make an unfortunate decision which I wouldn't be able to go back on once the project goes over 2-3kloc... without introducing hundreds of potential runtime errors, that is.

View on HN

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.

One way is to use regression unit testing, though Clojure community is not very into testing.

I've noticed the complete opposite. There's less of an emphasis on unit tests, but that's because the nature of FP enables you to need less of them. Instead of needing to check (at least as often) if objects behave correctly, you can write the few tests necessary to give you some regression abilities later on.

I've noticed a huge emphasis on testing the sytem, specifically through means of generative/property-based testing.

That last part is complete rubbish.

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.

Did you respond to the wrong comment? He says it's rubbish that the Clojure community is NOT into testing.

I misunderstood sorry!

That's just what I've heard - sorry if it's incorrect.

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).

If the testing isn't automated, I'm not sure it should really count.

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.

Reply on news.ycombinator.com