| 10 Dec 2024 |
 jade_ | In reply to @9999years:matrix.org
but nothing actually checks them i want to completely Obliterate the fixture system and replace it with one that mandates annotations and just has a registry of fixtures | 18:50:16 |
| jade_ | but this is like, totally doable with 100% source compatibility as long as we are hardasses about type annotations, and we keep the current situation where we kinda dont do anything that weird with fixtures in the first place | 18:51:19 |
| jade_ | like, the way that i see us using pytest is not using much of their discovery system, using their assert rewriting system, and none of their actual running/state code | 18:53:18 |
| jade_ | including possibly not using their fixture system either. the pytest fixture system exists to combine context managers imo | 18:53:43 |
| jade_ | its a syntactic hack to deal with nesting of context managers. if you introduced a composition primitive for context managers, it would become far less interesting.
now yes there is sharing of those and maybe we want the ability to do that, but i think theres got to be different ways we can actually achieve the sharing; i dont personally care that much about sharing in our use case | 18:54:36 |
| jade_ | https://git.lix.systems/lix-project/lix/issues/594 anyway here is the rfc issue for possible pytest replacement | 18:55:07 |
| jade_ | but like, i think it is easy enough to preserve adequate source compat that we can replace pytest in the future | 18:55:26 |
| jade_ | https://git.lix.systems/lix-project/lix/issues/600 here's another value-adding thing that could be built for the test suite
there is the other question of whether python is the right choice. i still do think it is, since it is highly unfortunate to have to eat the build time and worse iteration loop of rust or so, and i would strongly prefer to avoid having more C++ especially due to its effects on build time. it is a bit more accessible than rust also. there is also no barrier to using it since it is an unavoidable forced lix dependency due to meson.
rust tooling is nice and does allow for directly linking to lix and thus in the future maybe more reuse of fixturing for unit vs integration tests (but execve() exists also for stuff like fixturing a web server, so idk). however, libtest being very tightly coupled to the compiler makes it quite hard to do particularly interesting things with rust test suites, and there is no well-integrated solution to the problem of sharing fixtures or so. i think in general python gives us more flexibility but i think it is important to commit to something rather than letting ourselves get too busy yak shaving.
regardless of what we choose to do we are going to have to invest a fair amount of time in fixturing work to make writing tests nice. | 19:31:19 |
 Charles | if i were to write a test suite thingy in rust i would probably just write it as a regular crate, not using any existing test harness; idk | 19:42:58 |
| Charles | i feel like python is a reasonable choice | 19:44:34 |
| Charles | i don't really have a horse in this race, so sorry if me sharing my opinion is more annoying than anything else | 19:44:51 |
| jade_ | i do appreciate you sharing your opinion though; knowing that pytest is indeed painful in the expected ways is valuable info | 19:47:15 |
| jade_ | if we would be writing it as a normal crate, it puts both rust and python on the same playing field, that we would be writing a runner | 19:47:42 |
| jade_ | puck: do you know how to figure out why our gerrit is sitting here on 100% cpu on two cores? my specific annoyance is trying to use the ssh cli and having it not answer ssh gerrit gerrit --help | 19:49:35 |
 piegames | One minor annoyance I have with current functional-lang is that everything is just thrown into some huge flat folders. I find these pretty uncomfy to navigate | 19:50:38 |
| piegames | also having to touch multiple files per test is tedious as well IMO | 19:50:51 |
| jade_ | yeah | 19:51:51 |
| jade_ | oh speaking of which let me file another feature request for functional2 | 19:52:04 |
| jade_ | specifically a little DSL to throw stuff into the test-dir | 19:52:16 |
 puck | In reply to @jade_:matrix.org
puck: do you know how to figure out why our gerrit is sitting here on 100% cpu on two cores? my specific annoyance is trying to use the ssh cli and having it not answer ssh gerrit gerrit --help uhhhhhh, jdwp it? :p | 19:55:15 |
| puck | i'm probably not able to do this rn | 19:55:24 |
| jade_ | alright i can try to attach uhhh visualvm to it i guess | 19:55:36 |
| puck | https://github.com/patric-r/jvmtop/blob/master/doc/ConsoleProfiler.md hmm | 19:56:40 |
| jade_ | In reply to @jade_:matrix.org
specifically a little DSL to throw stuff into the test-dir filed | 19:56:42 |
| Charles | something else that might be worth investigating is snapshot testing. snapshot testing really excels when you need to run the same testing logic on different inputs and assert on the outputs | 19:56:47 |
| jade_ | theres an expecttest issue filed on lix, and i implemented expect testing that is as good as the rust one on the train to here :3 | 19:57:48 |
| jade_ | it is merged into the upstream expecttest python lib, just needs a release | 19:58:00 |
| Charles | very nice | 19:58:05 |
| jade_ | Expect("""foo""").assert_expected("bar") does exactly what you think it does | 19:58:29 |
| jade_ | and can rewrite the sources | 19:58:38 |
