4 ms·

I used to be TDD fanatic with java junit + spring unit tests and I went for 100% test coverage . However, in my Clojure code, I feel 100% test coverage is

I used to be TDD fanatic with java junit + spring unit tests and I went for 100% test coverage . However, in my Clojure code, I feel 100% test coverage is unnecessary. REPL does a good job of proving my code works as intended. I wonder if I am doing it wrong!

BorgHunter 12y ago
Unit tests are only partly to prove your code works when you initially write it, though. They also have significant value in allowing others—or Future You—the confidence to touch nearby code without feeling scared of breaking things. This is very important in Java and similar languages; in Clojure I suspect¹ this is less important just because functional styles lend themselves better to obviously-correct code. ¹Disclaimer: I have no experience with Clojure, working primarily in Scala these days. I do aim for good unit test coverage in Scala just the same as I did when I worked in Java.
alextp 12y ago
I write tests not to convince myself my code is correct (it often is, and repl and ad-hoc testing are more than enough to make sure it does the right thing now) but to prevent myself & future others from breaking it as they maintain it in the future.
wpietri 12y ago
A REPL does a good job of proving your code works as intended now. If you save that code in a file and run it regularly (which is a fine way to start making a test suite), then you can prove your code still works later. That's especially important when multiple people work on a project: you have some chance of remembering what important REPL incantations prove a system works. They won't. If you haven't put your REPL magic in a test suite, then they're going to break your stuff.
aardvark179 12y ago
The problem with that style of testing at the repl is it proves your code worked for those tests at that time, but unless you turn that into test cases that will keep on being run then there's a good chance that you'll forget one of those test cases in the future. Trust me, a large, old, code base like that is terrifying to work with. Don't obsess over code coverage though, concentrate on areas of risk and scenarios, I've written code with 100% coverage that still had an exciting range of bugs, and I've seen extremely robust code that had relatively low coverage overall but had tests focusing on the really tricky areas.
rdtsc 12y ago
I defense of unit tests, if REPL is not automated then you are losing that aspect. Yes the first time your write something it works fine to manually run things in a REPL. But next time you refactor or a coworker updates your code, you want to be able to run the tests and find what has happened.
CmonDev 12y ago
You are choosing to not unit test a dynamic language project?
ianbicking 12y ago
The Doctest approach (https://docs.python.org/2/library/doctest.html https://docs.python.org/2/library/doctest.html) is kind of a way of formalizing the REPL – you still essentially have a REPL, but you have the interaction written down in such a way that you can re-run it. Often you can copy-and-paste your REPL interaction into a document and then it's a test. It's a little more work because the computer doesn't know what "close enough" is – so something that includes a timestamp, for instance, causes failures (since it always changes) unless you annotate the expected output a little.

BorgHunter 12y ago

Unit tests are only partly to prove your code works when you initially write it, though. They also have significant value in allowing others—or Future You—the confidence to touch nearby code without feeling scared of breaking things. This is very important in Java and similar languages; in Clojure I suspect¹ this is less important just because functional styles lend themselves better to obviously-correct code. ¹Disclaimer: I have no experience with Clojure, working primarily in Scala these days. I do aim for good unit test coverage in Scala just the same as I did when I worked in Java.

alextp 12y ago

I write tests not to convince myself my code is correct (it often is, and repl and ad-hoc testing are more than enough to make sure it does the right thing now) but to prevent myself & future others from breaking it as they maintain it in the future.

wpietri 12y ago

A REPL does a good job of proving your code works as intended now. If you save that code in a file and run it regularly (which is a fine way to start making a test suite), then you can prove your code still works later. That's especially important when multiple people work on a project: you have some chance of remembering what important REPL incantations prove a system works. They won't. If you haven't put your REPL magic in a test suite, then they're going to break your stuff.

aardvark179 12y ago

The problem with that style of testing at the repl is it proves your code worked for those tests at that time, but unless you turn that into test cases that will keep on being run then there's a good chance that you'll forget one of those test cases in the future. Trust me, a large, old, code base like that is terrifying to work with. Don't obsess over code coverage though, concentrate on areas of risk and scenarios, I've written code with 100% coverage that still had an exciting range of bugs, and I've seen extremely robust code that had relatively low coverage overall but had tests focusing on the really tricky areas.

rdtsc 12y ago

I defense of unit tests, if REPL is not automated then you are losing that aspect. Yes the first time your write something it works fine to manually run things in a REPL. But next time you refactor or a coworker updates your code, you want to be able to run the tests and find what has happened.

CmonDev 12y ago

You are choosing to not unit test a dynamic language project?

ianbicking 12y ago

The Doctest approach (https://docs.python.org/2/library/doctest.html https://docs.python.org/2/library/doctest.html) is kind of a way of formalizing the REPL – you still essentially have a REPL, but you have the interaction written down in such a way that you can re-run it. Often you can copy-and-paste your REPL interaction into a document and then it's a test. It's a little more work because the computer doesn't know what "close enough" is – so something that includes a timestamp, for instance, causes failures (since it always changes) unless you annotate the expected output a little.