Clojurians Log v2

You can check reagamis tests

I happened to land in JSDom. Eucalypt uses happydom. Don’t have much experience with both

Thanks! Will take a peek.

Hot take: Don't couple code to the DOM 😅

except when you're creating a DOM patching library, then it might be handy to check if it works

Sure, but you don't want to be in a situation where you can only check if things work by going through the DOM

Replicant uses a protocol in front of the DOM to spare me the suffering of needing to run tests through a DOM

then you're testing the protocol. I want to test if things actually work in the real world

With a protocol you can do that as well

for example the input range min/max/value thing, you wouldn't catch that if you just test a protocol or instrument your code

No, but you can still write a test for the situation

I don't think you'll ever unit test yourself into such a case. You'll discover the problem through real usage. The question is: can you write a test that ensures you don't have that problem again? I can, even if I test against a protocol.

In any case, you could make an argument for coupling your tests to the DOM, but it still isn't a good argument for coupling the implementation to the DOM 🙂

I'm sure you can, but why test something fake if you can test the real thing. it's like testing a mock. I try to avoid mocks. I try to avoid unit tests as well. I tend to test systems, not just parts

I mostly agree with you. But I don't think this is a good reason to couple your implementation to a browser.

what do you mean with "implementation and browser". what's your problem man

:P

I don't even know what you're accusing me of

hey cjohansen, this is a question about a dom library. i'm not sure what purpose you have for saying that a dom library shouldn't be used.

I am obviously not expressing myself well. Sorry for that!

there's a question and potential answers. i think if you have strong feelings about not using dom libraries, those would be better suited for a different thread

to be clear, i'm not a mod, just wondering what the goal here is

it's fine. let him speak. :P

The way I read this thread: My code is coupled to the DOM, how can I test it? My hot take answer is: don't couple your code to the DOM and test it the conventional way. If the question instead was "how do I integration test with the DOM" then I am misguided, and apologize.

I haven't tried to accuse anyone of anything, and certainly did not mean to suggest someone shouldn't use "dom libraries". I just think coupling code to the DOM is a bad idea, but I understand my hot take is not appreciated, and will shut up now 😅

no worries, glad we could clear it up!

it's fine. I appreciate it. I was just joking around while disagreeing on some things you said, because my reference is reagami, which is a DOM patching library. There I want to know if it actually mutates the DOM in the way I'd expect, e.g. is the node rendered the same reference. When testing applications, you're probably in a different game

I still think "I want to know if it actually mutates the DOM in the way I expect" is orthogonal to whether or not the code (specifically the implementation, not the tests) is directly coupled to the DOM. That was the point I was trying to make.

Example: Let's say your DOM morphing library can manipulate CSS properties. You might want to write several tests for how the library interprets Clojure datastructures into CSS. You need at least one test to make sure the style property of the DOM node is manipulated, but the bulk of tests could be written for how the library manipulates data.

I was out raking leaves. I filled 11 bags. My word!

Hot takes are welcome!

That's where I think we differ. I've seen enough breaking tests where the ideal platonic world survives a "unit test" until it hits the real world. I want to see the system working, not just a part.

So yeah, my first cljs go at the cljdoc front end was to simply transcribe it from TypeScript to squint cljs. That's where I'm at. I am wholly unsophisticated. simple_smile

I'm not necessarily talking about a part of a system. I'm saying that you can test that one aspect of the system works in the intended runtime, and then add a hell of a lot of more examples of that same behavior that runs faster by leaning on that one full example. This is not really a unit vs integration test thing. Besides: by not making the code directly coupled to the DOM, you open up for the ability for the code to work against targets that are not the DOM.

I can now at least understand it and maintain it!

The idea of localizing code that mutates the DOM makes sense to me. That's not what cljdoc code does. But it makes sense to me.

It all makes sense to me but there's always different trade-offs. It's not like protocols are totally free in terms of performance either.

But then again, cljdoc has a relatively teeny weeny front-end. So I might leave it as is unless it causes me problems.

@lee what are you actually testing? aren't you maintaining a library called #etaoin that can help you with that? ;)

They're not. But I think (hope?) that their cost is low relative to updating the DOM, and not really a bottle neck. I think I may even have tested this, but I'm not sure.

Ha! Yeah, I could use etaoin, but I've been traumatized by flaky webdriver tests while maintaining it!

just for the record, @lee is just using squint + preact (comes down to as if you just wrote JS + React basically in terms of testing).

Yes, my hot take may have been entirely misplaced. Sorry!

I could reconsider etaoin @borkdude. It is pretty reliable on Linux. I really just go through a short manual checklist. Or I could just keep going through my short checklist manually. simple_smile

@christian767 nice, to see you so fired up and passionate!

if your take is: you should just test the hiccup that's generated like in replicant: my feeling is that you don't even need to write a test for that - hiccup is just data. you may want to just skip that stuff entirely and not even include a rendering library for testing. unfortunately my experience with browser testing is that it sucks and is brittle almost always.

people have had good experience with playwright: you can record your clicking around and stuff (and then also generate JS from that). haven't really tried it.

my worry is more that there's something not working in the browser than the front-end logic and if you skip testing that part, you may just be fooling yourself

it's like testing stuff with databases. it's all nice testing isolated functions that emit events and stuff, until you discover that the database is dropping data for some crazy reason

@borkdude The goal with Replicant certainly is that its user should be able to adopt such a naive approach to testing. From my own experience as an application developer I would say it's quite successful at this. As for Replicant's own tests, most of them are about which operations Replicant will perform in certain scenarios. They have helped me a lot, but surely also left some holes. But I don't think you can blame the testing strategy for that. Sure, Replicant had a bug with input ranges, but it also didn't have a single input range test - it hadn't occurred to me. It now has several, and none of them touch the DOM. They're probably not as good as the real thing, but by how much? And what do they gain from this disparity? I can make sure that it generates the right HTML string for server-rendering with the same test. That's something.

I think it's telling that I ran into these bugs by just re-creating some reagent examples in my from-scratch reagent-clone in a few days and was able to fix them pretty quickly. The test may not look as nice as a pure-data test, but the writing the test wasn't my bottleneck at all.

I want a test where I don't have to encode "this should be done before that" but "this will fail because the browser behaves like this". The this before that thing is just a way of preventing the failure. If you are testing that, then you are testing an implementation.

It's telling that you ran into the bug by recreating the examples. But it's not telling a lot about automated test strategy 😊 it does tell that you're very meticulous and methodical in how you approach things. I mostly make shit for myself. That affects my focus and horizon. This definitely reflects well on you, but I don't think the approach to automated testing has any bearing on this issue.

Well, my innocent question triggered a very interesting discussion! I think borkdude is saying that without integration tests, he can't trust that his code works. And that he favours integration tests over unit tests. And cjohansen is saying that with solid very well tested dom abstractions, he can trust his unit tests enough to tell him his code is working. Is that a good summary?

the approach to automated testing reflects on this issue exactly the way I wrote it: I want to test actual browser behavior because browsers are messy. I don't just want to test the platonic data-world stuff. 99% of clj-kondo's tests are written in this way too. real world scenario's going through the file system. not just "test this tiny function to see if it finds this particular case in this re-write-clj node"

yeah, good summary

Yes, I've very much noticed this is your preference when working with you over the years, borkdude.

if you are the user of a library like replicant or something else, that's a different game. you shouldn't have to re-test that library. I agree with that

but I'm talking about testing the library here

well maybe for applications, I wouldn't blindly trust the library either

anyway

I still love you @christian767

It's a roughly accurate summary of where we ended up, but not really my initial point. I'm of the opinion that what you include in your tests is orthogonal to what you couple your code to. I agree that unit tests can fail by focusing too much on details, but I don't agree that this means every test should be an integration test.

orthogonal is such an overloaded and overused word

I've tended to like both. Unit tests can help me write and verify my code. And integration tests tell me my app/lib is working as a whole.

> I agree that unit tests can fail by focusing too much on details Detail isn't my point at all. The point is that the unit test doesn't hit the stuff that is most often where the problems are. Detail is the wrong word: it's just not testing the most likely point of failure. It's not about detail

I'm also not against unit tests. I don't force integration tests on everything. There are functions that are purely data and I write unit tests for those as well (e.g. in clj-kondo's type system for example)

That's roughly what I meant by "detail". I think we agree on this 😊

well yeah, unit tests can focus on implementation details too much. and they are a pain to change when your internal implementation changes

I think we all know this, it's not like we're discovering new ideas here

Maybe orthogonal is overused. But still, wanting to test everything through the DOM is a separate decision from whether the implementation should be hard coupled to the DOM. Coupling the implementation to the DOM means tests must involve the DOM. Not coupling the implementation means you can choose to involve the DOM or not.

But do you know what we did discover? That you love @christian767, and that's nice.

Hehe

Mission accomplished

I still don't know what you are referring to with "the implementation".

The code that isn't the tests

at some point some code somewhere needs to deal with the DOM. so what code are we talking about here.

I've watched @christian767's video series on Replicant. I think it illustrates what he is talking about. And maybe goes back to my summary point.

are you referring to "implementation" from the original post maybe?

I'm talking about what the code assumes and what is pluggable. If the code calls directly on the DOM, I'd say it's hard coupled because it assumes it's the only way to achieve its goal. If the DOM is behind some sort of abstraction, I'd say it isn't hard coupled. By "the implementation" I'm really talking about all the decisions the code makes around the DOM operations it needs to perform. But I don't think we'll agree on this on Slack, so maybe we've come as far as we'll come. I'll be at Dutch Clojure days 😊

I think I'm still confused by what you mean with "the implementation" and "the code".

you can't keep inventing layers of abstractions to hide away a problem, at some point you need to hit something in the real world

but sure, let's talk at DCD. Are you coming to Babashka Conf too, the day before? https://www.meetup.com/the-dutch-clojure-meetup/events/312079164/?slug=the-dutch-clojure-meetup&eventId=312079164

(there's only 10 out of 50 places left... after 1 day)

Just signed up!

Are you sending something in for the CfP for DCD?

you have more experience with writing front ends than me obviously. if you say that testing an abstraction works 90% of the time and for the remaining 10% you maybe write some more gnarly tests that might involve the DOM if you really have to, I believe you. it's great that this is working out for you. I'm really sceptical when it comes to computers working. Maybe I should start trusting browsers more.

I'm planning to send something to the CfP yes!

can we guess which project it will be about?

I haven't decided yet, otherwise it would already be in 😊

So to answer my original question: It depends, there are many different schools of thought and preferences.

don't trust me, trust browsers

gotta do some 💤 now

Good night, folks. Thanks for this thread. It was interesting, fun, and also Clojurely in its spirited yet diplomatic tone.

Plot twist: writing Eucalypt tests I discovered that happy-dom diverges from the browser behaviour more frequently than I would like. laughcry