Re: [tlug] Constructed state, unit tests and REPLs

[Josh Glover <jmglov@example.com>]

On Thu, 3 Sep 2020 at 10:55, Curt J. Sampson <cjs@example.com> wrote:

On 2020-09-03 09:59 +0200 (Thu), Josh Glover wrote:

> I write veeeeeery few unit tests these days [because of] REPL-driven development

That seems...odd. Do you not write tests because the code is "tested"
sufficiently from indspection? In that case, what use is the REPL? Or do
you test in the REPL? If so, doesn't get tedious typing the same tests over
and over again when you could just type them once and let them be run
automatically?

This might be just one of the things you'd have to see to understand. I build the code up incrementally, focusing on one aspect at a time, experimenting as I go. There's no retyping of tests as such, because I'm not writing tests in the REPL, I'm executing code. I'm interested in what the output is, but not in testing that it's correct, because at that stage, I don't necessarily know what "correct" looks like. I do of course validate that the output is what I expect, to make sure I haven't made an error or have faulty assumptions, but I'm unlikely to execute the same code over and over again, as it hasn't "set" yet. It's kind of like molding clay, I guess.

As for retyping, my REPL has history and structural editing and all that good stuff, so to the extent that I evaluate the same or similar s-expressions multiple times, it's not onerous to do so. It's more onerous to write a test in a file that might become useless moments after I write it because of a faulty assumption about the shape of the return value from AWS or something.

These days I find even even switching to a REPL or command line to be too
tedious;

In lisp, I'm not switching to the REPL per se. Often I'm just working in my source buffer, evaluating expressions and seeing the result. Switching to the REPL is as easy as C-c C-z (for Clojure with CIDER), so I don't experience any tedium there.

 

I don't know how I used to put up with moving my mouse pointer to another window

What's a mouse? ;) 

> I mainly develop the functions, write property-based tests, and then write
> a few example-based tests (AKA unit tests) for public functions to show
> people the intention of the functions and how to use them.

Yeah, that's what I can't really figure out. If you feel the need for
property-based tests (or any kind of tests), why not write them first?

Because I don't know what functions I need ahead of time, and I don't know what properties they should have. The property-based tests are there to validate that what I think the functions do is actually what they do, and to guard against regressions.

 

Almost invariably documentation and tests are each more time 

and work than writing the code that will run in production.

Absolutely! That's why I write the tests and docs after the code, so that I don't have to spend time updating them after I realise that my initial design and assumptions were incorrect somehow.

I think this boils down to our minds working in different ways, and this is why Haskell never felt like home to me for anything but koans and practice problems. I completely agree that programming in Haskell is largely a matter of writing down the types, and then the code almost writes itself. This is awesome when it's easy to figure out the types, like if I'm implementing foldr or something. It's a lot harder when I have to deal with JSON coming into my program, which may or may not be what was specified, and I'm trying to use libraries that are new to me, where I might not know which combination of functions is the right thing to do what I want.

My experience with Haskell has been a lot of up-front design, and I simply can't do this very well in my head. I need to try things out as I'm designing, and make sure the public interfaces I'm creating are ergonomic for clients. It sounds like you can do this in your head, and thus prefer to write tests first, because you're pretty confident that your design will hold as you implement it.

Again, I'm not at all critical of that, but I do think that a lot of people arguing strenuously that strong typing is inherently better than dynamic typing are assuming that everyone's mind works the same way theirs does, and that everyone is writing the same sorts of programs they are.

And at the end of the day, I'm not interested in arguing which is better. I'm more interesting in arguing that a programming using languages and tools they are comfortable with and that bring them pleasure is more productive than trying to use something that's "better" but with no empirical data to back that up (unless you're writing software with really high verification requirements, where strong typing is basically a requirement).

> It would be cool if we lived in a world where you and I could sit side by
> side and hack code

Well, we do live in such a world so long as you're willing to use a few
tmate windows and Telegram voice chat.

This would be interesting. I'll put it on my backlog and see if my free time lines up with your working time. :)

--

Cheers,
Josh