• vanillama@programming.dev
        link
        fedilink
        arrow-up
        4
        ·
        1 day ago

        Agreed, you find the right shape for the code as you build and try stuff, adding the tests right after makes most sense, unless maybe you’re just testing an API or something

        • Zannsolo@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          23 hours ago

          I mean I’m theory for any planned method you would know the input and expected output before the coffee is written.

          • ThirdConsul@lemmy.zip
            link
            fedilink
            arrow-up
            2
            ·
            16 hours ago

            Except that then you’ll shape your interfaces to drive tests nicely, instead of being, you know, sane and useful (been there, done that).

            • 3abas@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              8 hours ago

              Unit tested test for accuracy, if your code isn’t “shaped to drive tests nicely”, it’s bad code.

              They enforce requirements. You do start with code, you start with the “shape”, you architect how your application should be developed and you write unit tests for the functions you already know you want but haven’t written the logic to yet, the unit test validates the logic so you don’t spend 2 hours hunting down a missing negative sign.

          • vanillama@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            15 hours ago

            As I said, an interface can easily be tested, but if it’s internal implementation I normally make a design, implement it, and I usually come up with other ideas and I like having the fluidity of making changes as I prototype and such, that way I’m not constrained by a test yet. After I’m done, and documented my choices if necessary, then I add the tests.