@cjhowe you have a pure render function. If you actually want to “test” the UI, you could do visual regression testing like this: https://medium.com/adstage-engineering/how-we-test-our-full-stack-clojure-app-b18d79ee9e00 I personally find a very low return on investment in end-to-end testing from the UI. But the visual regressions are a cool idea.
yeah, i kinda agree about end to end tests, but i need to test my components somehow. regression testing sounds like a good idea
If your data model works, and your UI renders properly when given correct data, then you’ve pretty much got it. The rest of the bugs would be in “hooking it up”, which are easy to catch, and easy to fix
e.g. rarely regress in a way that automation is going to help with (from a cost/benefit perspective). I’ve been at places where we paid $150k+ for people that did nothing but write and maintain e2e tests that rarely caught anything useful (and never caught anything real that a better testing approach couldn’t have caught better, with more clarity, less maintenance, and fewer false positives)
sounds like i should just wait until i have specific problems i would need those tests to solve
I like e2e tests for smoke testing: is the system, in general, operational. Very low coverage, but kicks the tires. useful for devops and such.
sure, that's a good use case
i really hate writing end to end tests
I also like to integration test (e.g. at a given layer). For example, when I was recently developing fulcro-sql, I wrote quite a few tests that actually hit a live database. Then I write logic tests on the bits of layer above that, etc. I get pretty good results, with pretty compact and maintainable tests.
but I try to limit the integration tests to very small bits, so failures are clear about what’s wrong.
thanks for the wisdom! i'll definitely take this into consideration
welcome