Conversation

Notices

1. Embed this notice
   screwlisp (screwtape@mastodon.sdf.org)'s status on Monday, 15-May-2023 13:05:29 JST screwlisp

   1. write test
   2. write functions for test
   3. write different functions
   4. forget to update test
   5. ?????????????????????????????????????????

   • Embed this notice
     𝚛𝚊𝚝 (rat@mastodon.sdf.org)'s status on Monday, 15-May-2023 13:07:46 JST 𝚛𝚊𝚝

     in reply to

     @screwtape it's a cult

     screwlisp repeated this.
   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Monday, 15-May-2023 13:11:56 JST screwlisp

     in reply to

     • 𝚛𝚊𝚝

     @rat ++ I dunno the mitigation for me forgetting that I changed the way things worked though. I wonder if I should do something fanciful like walk functions in the packages in a particular file when checking something works. Something so I can get an error like "what you are doing doesn't reflect current reality". But this sounds like I'm just being passive aggressive towards myself.

   • Embed this notice
     𝚛𝚊𝚝 (rat@mastodon.sdf.org)'s status on Monday, 15-May-2023 13:17:36 JST 𝚛𝚊𝚝

     in reply to

     @screwtape "more tests" 😆

   • Embed this notice
     Paul SomeoneElse (pkw@mastodon.sdf.org)'s status on Monday, 15-May-2023 14:23:29 JST Paul SomeoneElse

     in reply to

     • 𝚛𝚊𝚝

     @rat @screwtape that's not TDD?
     You update your tests first to fail, and then write your different code after to pass.

     I'm not a fan of TDD except for opt-in voluntary use of it for things like business logic in code. Or when you are writing code with very precise requirements spelled out ahead of time.

     I think the cult of TDD is a cult. But the practice of it can be useful as a tool.

   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Monday, 15-May-2023 14:25:46 JST screwlisp

     in reply to

     • Paul SomeoneElse
     • 𝚛𝚊𝚝

     @pkw @rat so I kept looking at my (fine but new) logic after my test that made sense before, but no longer made sense without checking what the test was. I guess my test name / error was not usefully descriptive as well.

   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Monday, 15-May-2023 14:40:54 JST screwlisp

     in reply to

     • Paul SomeoneElse
     • David K. Trudgett
     • 𝚛𝚊𝚝

     @datalinkdroid @pkw @rat so you're pointing out that I should be using cl-prove in a natural way or something. But my test was ad hoc: Initially, some bitfield bits were meant to be one. My test reflected this. Later, they were meant to be zero, and all later tests reflected this. So I had a mixture of old and new ad hoc tests. I guess what you're saying is that this kind of quick test was not an appropriate approach at all, and I paid the price for my foolishness.

   • Embed this notice
     David K. Trudgett (datalinkdroid@mastodon.sdf.org)'s status on Monday, 15-May-2023 14:40:55 JST David K. Trudgett

     in reply to

     • Paul SomeoneElse
     • 𝚛𝚊𝚝

     @pkw

     @rat @screwtape Like "Design Patterns", TDD is a bad smell that normally indicates a shortcoming of the development language in use. For instance, the pre- and post-conditions of subprograms need to be expressed in the language itself, and not bolted on externally to the program. Types need to be defined such that you cannot assign a temperature to an altitude, and so on. With these kinds of capabilities, many tests do not need to be written: the faults cannot happen.

   • Embed this notice
     David K. Trudgett (datalinkdroid@mastodon.sdf.org)'s status on Monday, 15-May-2023 15:02:41 JST David K. Trudgett

     in reply to

     • Paul SomeoneElse
     • 𝚛𝚊𝚝

     @screwtape

     @pkw @rat

     Well I don't know what you did and didn't do, so you are safe from my judgement lol. :-) I do know that CL is a pretty cool language, though. Better than most, and I use it myself, but it does have some weaknesses, like all of them. I am always torn between CL, Perl and Ada, all of which do /something/ far better than anything else I'm familiar with.