Fork me on GitHub
#babashka-sci-dev
<
2024-06-10
>
teodorlu06:06:21

Morning 🙂 I’ve been thinking about the Neil codebase. We run several tests with real http requests to maven / clojars / github. As of latest master, test suites complete in 45s (bb) and 36 (jvm). (Which is very good compared to some code bases that I’ve worked on). I’ve been wondering if it makes sense to try separating the http requests from the pure logic a bit. If it’s possible to run most (all) of the logic without starting HTTP requests to remote endpoints, we could possibly speed up the test suite, or make it cheaper to add new tests. And possibly test whether our Maven/Github/Clojars code does as expected once, then test our code separately. Thoughts? I suspect this might require a bit of work, so I don’t want to start off if it doesn’t make sense.

borkdude09:06:29

I usually write tests in an "integration test" kind of way, from a user perspective, rather than a technical perspective. We have to test the whole chain anyway, and it avoids having to change/maintain a whole lot of stuff when internal stuff changes. I notice you're having a lot of fun with neil lately, thanks for that The project that needs the most love at the moment is probably bbin. If you want to help out with that, this would be more valuable to me than optimizing tests :)

👍 1
borkdude09:06:11

One thing that does annoy me a bit with the neil tests is that dependencies changes (newest versions) and this requires the tests to change as well, but there's probably not a lot that can be done about this and it's a minor nuisance to me

👍 1
teodorlu10:06:47

Gotcha, thanks 👍 Agreed about hard-coded versions of libs.

teodorlu20:06:42

> One thing that does annoy me a bit with the neil tests is that dependencies changes (newest versions) and this requires the tests to change as well, but there’s probably not a lot that can be done about this and it’s a minor nuisance to me One idea: 1. Pull latest version info into a file 2. Use that file from the tests 3. Script updates of that file (eg trigger with bb gen-testdata) Still has to be updated manually, but then updates can be done in one command. Still not super happy with ☝️, as the tests will be more obscure if they depend on data in a file.

borkdude20:06:14

I might as well just update the versions in the code when the tests fail instead of in the file?

teodorlu20:06:58

Yes, indeed.

teodorlu07:06:15

Those test updates. Perhaps we could replace asserting version equal to something with asserting that the version is greater than or equal to something using version-clj. Then nothing has to be updated in the tests.

borkdude10:06:13

Interesting idea, let's keep it in mind. For now I'm not too bothered by this

👍 1
teodorlu10:06:54

Thoughts on a good place to start to improve bbin? I see 20 open issues, but I don't know what's important or "near a specific thing that could be done to improve bbin".

borkdude10:06:35

So 78 seems the most important to me, but the whole list above are the most important in general

👍 1
borkdude10:06:55

Thanks for having a look!

🙌 1
borkdude10:06:08

If you have any questions, feel free to bug me of course

❤️ 1
teodorlu11:06:57

Awesome, thanks!