Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^2: What to test in a new module

by Anonymous Monk
on Jan 29, 2023 at 02:50 UTC ( [id://11150004]=note: print w/replies, xml ) Need Help??


in reply to Re: What to test in a new module (TDD)
in thread What to test in a new module

> write the tests first

How are you supposed to write the tests before you write the code? What is being tested if there is no code? I searched for examples of this technique but could only find buzz word salad.

Replies are listed 'Best First'.
Re^3: What to test in a new module
by eyepopslikeamosquito (Archbishop) on Jan 29, 2023 at 04:44 UTC

    The term TDD is unfortunate because API design is fundamentally an iterative process, testability being just one (crucial) aspect. For public APIs you simply don't have the luxury of changing the interface after release, so you need to get it right, you need to prove the module's testability by writing and running real tests before release.

    More detail on this difficult topic can be found in the "API Design Checklist" section at On Interfaces and APIs. One bullet point from that list clarifies the iterative nature of TDD:

    • "Play test" your API from different perspectives: newbie user, expert user, maintenance programmer, support analyst, tester. In the early stages, imagine the perfect interface without worrying about implementation constraints. Design iteratively.

Re^3: What to test in a new module
by GrandFather (Saint) on Jan 29, 2023 at 21:30 UTC

    My Google search for "test driven design" got me Test-driven_development as a first hit. That is a short article that hits the high points and directly answers your objection - the tests fail until the code they test is written and is correct (at least in the eyes of the tests).

    TDD is a technique I use occasionally, but in each case I've used it the result has been spectacular success. When I have used TDD I've also used code coverage to ensure a sensibly high proportion of the code is tested. In my experience the result was seeming slow progress, but substantially bug free and easy to maintain (i.e. high quality) code as a result.

    Not all projects can use TDD. My day job is writing hardware specific embedded code for in house developed systems. Testing software embedded in hardware is challenging!

    Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
Re^3: What to test in a new module [When to test]
by kcott (Archbishop) on Jan 29, 2023 at 07:34 UTC

    This seemed like a perfectly reasonable question. I gave it an upvote which resulted in: "Reputation: 0". So, someone had downvoted your post. Why? Because you had the temerity to question dogma? I wasn't impressed with this but there's little I can do about it.

    As with many things, there's a spectrum with many shades of grey between black and white at the extremities. It is rare for either "black" or "white" to be optimal; a compromise somewhere in the "grey" is usually the best option. This applies equally to software development: writing all of the code first, then bolting on tests afterwards, is a bad move; similarly, writing all tests first, which will obviously fail until the code is written afterwards, is also a bad move; what is needed is a compromise.

    What follows is how I achieve this compromise. I'm not suggesting this is in any way perfect; it is, however, something to consider in terms of the principles involved. Probably the main point is that the "black" and "white" extremes are avoided.

    I start most modules with module-starter and use Module::Starter::PBP as a plugin. I like the templating facilities provided by Module::Starter::PBP but not the templates themselves (so I've edited those quite substantially). I have many versions of the configuration which vary depending on: personal code, $work code, Perl version, type of module, and so on — the following refers to personal code for v5.36.

    This gives me a directory structure along the lines described above. The module code looks like this:

    package Some::Module; use v5.36; our $VERSION = '0.001'; 1; __END__ =encoding utf8 ... POD templates and boilerplate ...

    The t/ directory will contain equivalents of the three 99-*.t Author Only scripts shown above, and a template for 00-load.t which looks like:

    #!perl use v5.36; use Test::More tests => 1; BEGIN { use_ok('__MODULE__') } diag "Testing __MODULE__ $__MODULE__::VERSION";

    Applying a global s/__MODULE__/Some::Module/ to that file gives me a working distribution. I can now run the well-known incantation:

    perl Makefile.PL make make test

    I have created application and test code in unison: the compromise.

    From here, the specifics will vary with every module; however, the main principle is to add small amounts of functionality and concomitant tests incrementally. Continue doing this until all functionality is coded and has tests.

    In closing, I'll just note that the OP's title had "What to test"; I've added "[When to test]" to my title indicating this subthread is straying from the original. We actually don't know if Bod had already written all of his tests except the one he asked about, or if he was adding tests as an afterthought. Assuming the latter, and rebuking him for it, was a mistake in my opinion.

    — Ken

      This seemed like a perfectly reasonable question. I gave it an upvote which resulted in: "Reputation: 0". So, someone had downvoted your post. Why? Because you had the temerity to question dogma? I wasn't impressed with this but there's little I can do about it.

      Likewise, I upvoted and find it strange that anyone should downvote. Whilst I see the logic of writing tests first, it does go against one's natural instinct and the tendency is always to create the code first. Questioning why we do things the way we do them should always be encouraged.

      As a small point, people who post anonymously get an upvote less often from me.

Re^3: What to test in a new module
by stonecolddevin (Parson) on Mar 11, 2023 at 00:04 UTC

    I'm going to get eaten alive for this but TDD is a something I think people adhere to in a dogmatic fashion without a lot of thought put into API ergonomics and organic development.

    I am 100% in agreement that your code needs to be tested to the point before you reach diminishing returns. I do not feel like cementing yourself in place by writing your tests first is the way to accomplish this.

    You write your tests first and now a) you are now going to try to fit your implementation into that mold and b) you now have 2 things to refactor until you reach stable parity with your design and implementation.

    Unless you're designing and writing code against a predefined spec/RFC, I really don't feel like strict adherence to TDD is beneficial. Code needs to develop organically and allowed to form its own flow instead of being hammered into a predefined hole of a certain shape.

    Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

      Unless you're designing and writing code against a predefined spec/RFC, I really don't feel like strict adherence to TDD is beneficial.

      To me, that's partly the point. If you can't write the tests because the spec is wrong/contradictory/woolly/absent then that's a problem with the spec. Test Driven Development requires a solid spec, otherwise it's a non-starter.


      🦛

        I agree up to the point that you're building to spec because someone said you need a certain endpoint just because they thought it feels good. I don't think everything gets done in design meetings and I think there needs to be some relatively well thought out code written before you say "ok here's our API spec".

        Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

      Code needs to develop organically and allowed to form its own flow instead of being hammered into a predefined hole of a certain shape

      This definitely resonates with me and the way I tend to create things. I'm not suggesting that I do it the correct or best way but, for better or worse, it is how I usually go about things.

      As an example, I've just finished writing an email editor in JavaScript and Perl. The 'spec'1 was that it has to be easy for a non-techie user to assemble components of an email (images and rich text), store those atomically and not in parts as I am using temporal tables. The stored data needs to be able to be edited at a later date and when sent out as an email, render reasonably well on Outlook for desktop and K9 for Android (I find if an email renders OK on both of those it will be reasonably alright on most email clients).

      Other than that, the 'how' of the implementation or the 'what' of the appearance I had no idea.

      I started off with the bit that I thought would be most difficult - the JavaScript rich text editor. I created something that did the basic formatting but also realised that execCommand is deprecated. I asked ChatGPT for help with what to use instead and it suggested Quill along with other options. So my focus changed from creating my own editor to integrating a pre-existing one. Then I had to solve the problem of adding blocks of rich text along with images and being able to drag and drop them to change order. All very different challenges to those I anticipated when I first took fingers to keyboard.

      From there, I found that the HTML output from Quill is unnecessarily verbose. ChatGPT again to find DOMPurify to clean up the HTML before it is passed to Perl and stored in a database - there is still some HTML cleaning needed by Perl before sending out the emails but that differs depending on whether it is going to be a preview in the browser or sent out as an email.

      The whole process from first key press to fully functioning system took about 4 days working just a few hours per day. I doubt (but don't know for sure) that I could have completed this in that time if I had written tests first. The only test it seems to need (and I'm open to being persuaded otherwise) is that allows people to create an email and that the email renders OK after being sent out. I certainly didn't envision what it was going to look like or the finer details at the start. It evolved organically.

      1 - This 'spec' existed nowhere other than in my head. This post is the first time it has been articulated.

        Yea what I've been trying to get across in this thread but apparently failing to do so is that it's a waste of time to write tests for a POC (unless you have like, a wrapper around a low level HTTP client that you have say, a GET and POST method, there's nothing wrong with writing simple tests for that since that's not going to change) until after you've gone through enough review iterations to confirm with all involved that everything looks good. If something comes up after that, I think it's a scope change and an entirely different can of worms.

        For personal projects I feel like a hard spec outside of a braindump of what you want to do really hinders you even more. Unless you have a good deal of experience in the domain you're working in I feel like you end up "prematurely optimizing" your API ergonomics because you've written out a bunch of API endpoint/method definitions without letting a workflow emerge.

        Long story short, make it work, make it clean, make it fast.

        Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11150004]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2024-03-28 20:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found