Threads for voyd

  1. 1

    I think nix is ready for careful industry adoption, so I’m super excited to see where you’re going with this!

    1. 1

      assert (form := page.query_selector(“form#foo”))

      It’s great, immediately started using it more.

      1. 4

        At any point in the last 6 months a third of my colleagues had COVID

        1. 14

          Counterintuitively, i think (some schools of) tdd are actually on the same page as this. By using tests to define interfaces we basically define the parts that “rarely” change, though it might be more often that what the author considers rarely. Can’t remember where, but some sources on tdd explicitly encouraged deleting tests if they a) are covered by other tests as well and b) do not specify behavior that you care about. That would leave us tests that are similar to what the author would have, again, ignoring different ideas of “won’t change”.

          The major difference is that tdd still encourages writing these tests to drive out the API for the API handler or repository. It forces us to be deliberate about the component’s API, if we don’t care about that then we don’t need to design it.

          (To clarify, the author doesn’t mention tdd. These are my thoughts and since the topics are not well differentiated I thought I’d share them)

          1. 2

            I think haskell would have a spread operator. I feel there might be a spot in the design space with the right amount of flexibility to make this very useful without having bad type inference or ready misuse

            1. 4

              I think pooling these efforts is great, and I’m looking forward to the releases

              1. 39

                I find “should” in test names to be a noise word that can be easily eliminated.

                Taking some of the examples from the article:

                should apply discount when total cost exceeds 100 dollars

                applies discount when total cost exceeds 100 dollars

                should create record for valid input

                creates record for valid input

                should return error code 1 for unknown error

                returns error code 1 for unknown error

                1. 12

                  I was basically about to sag the same thing.i want to add though that I’ve seen this “should” approach greatly help people manage the mental switch from the test_functionname pattern, but yeah, once you feel okay take off the training wheels

                  1. 3

                    This all just feels like a ton of unnecessary noise to me. I actually do test “should return error code 1 for unknown error” right here: The test is called TestGet_default. I think if it were somehow confusing “why is it checking for 1? what does 1 mean here?” it might be worth having a comment or a longer test name, but in most cases what the test is testing for should be obvious and if it’s not (like the discount example), then that means the API in the code probably isn’t as clear as it should be.

                    1. 4

                      Agreed. I’m not a fan of verbose test names like this, especially when it’s done using one of those cutesy DSLs, like it().should().be().equalToOrGreater().than(42). Just call it TestRange or TestMin or whatever.

                      Nit: the test above is actually called TestGet/default. See go test -v ./... output:

                      --- PASS: TestGet (0.00s)
                          --- PASS: TestGet/wrapped (0.00s)
                          --- PASS: TestGet/nil (0.00s)
                          --- PASS: TestGet/default (0.00s)
                          --- PASS: TestGet/help (0.00s)
                          --- PASS: TestGet/set (0.00s)
                      1. 1

                        Re: Nit, I couldn’t quite remember how t.Run gloms names together, thanks.

                    2. 1

                      Good point! I should’ve mentioned that I’ve mostly used test frameworks which require a certain naming convention to detect tests, such as Pytest’s default test_ prefix, which can be overridden but (AFAIK) not avoided completely.

                      1. 2

                        It definitely does depend on the testing framework you’re using!

                        As another reply pointed out, this works best when you’re using a DSL where you setup tests similar to this:

                        it('does the right thing', () => {});
                    1. 1

                      I love systemd timers, only thing they lack is error Mail Integration like cron. Which belongs one level up probably, but still…

                      1. 3

                        You can use ExecStopPost= or create template service that will send e-mail on service failure.

                        1. 1

                          You could use (or similar - there’s a few options) as a wrapper which supports more fancy stuff like sending the script error to rollbar.

                          1. 1

                            I guess the proper way of dealing with this would be to do some kind of integration via DBus to know if a unit failed.

                          1. 5

                            Recently moved a project away from this to poetry. We have 2 separate applications which both depend on a shared library. Before, each had a and a for testing and dev tooling that shouldn’t go to prod (plus the .txts of course). Let’s say, updating those was fun and in our container images, we had to reconstruct the directory structure since we used PYTHONPATH to wire it up.

                            I guess the common package should have been a proper package from the start, but replacing everthing with poetry felt nice.

                            Next step, nixifying everything for caching 🙂

                            1. 4

                              I guess the common package should have been a proper package from the start

                              I’m not trying to be mean here, but my experience is that most of the time when people have stories about how Python packaging was awful/difficult/complex/problem-causing for them, at the root is always something like this, where a decision was made to go against the natural/standard flow. Building a Python package and then installing it into multiple deployed things really isn’t that difficult (you can learn how to build a basic Python package in an hour or so from the official documentation) — what was difficult, seemingly, was dealing with the consequences of deciding not to do it.

                              1. 1

                                To be clear, we didn’t have a whole lot of pain with what we did, it just felt like a relevant experience to the article.

                                We started simple and replaced it with something more appropriate once we outgrew it

                            1. 5

                              I think it’s confusing that they list credential stuffing as number one and explicitly connect it to password reuse, but then they later state that they are for the paranoid.

                              They also don’t mention that password managers a) limit impact of phishing and b) enable humans to actually rotate passwords on case of a breach or phish

                              1. 1

                                That’s where I stopped reading. They begin with assertions that seem reasonable but then say that credential stuffing means the password used is irrelevant because ‘they already have it’. I don’t know what the % of people using password managers is but … Chrome, Apple stuff - surely this is enough for us to say that plenty of people aren’t reusing passwords and that this blanket statement is therefore not just technically false but practically not true enough to state in such a way?

                              1. 3

                                I think this is a valuable switch of perspective, but taken together the bulk of these techniques sound like “write your own specific mocks instead of using a mocking library” to me

                                1. 1

                                  I think there is a difference still, perhaps just in that the scope of the “mocks” is smaller, but a more thorough explanation would be good.

                                1. 1

                                  Looks interesting, but I wish the code wasn’t so small on mobile