http://qs1969.pair.com?node_id=11150937


in reply to Re^10: What to test in a new module
in thread What to test in a new module

>Because they cement the specifications of the project.

My question is how do you know your specifications are correct/stable? You're testing all this code up until it is stable, how much of that testing remains in its original form?

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

Replies are listed 'Best First'.
Re^12: What to test in a new module
by LanX (Saint) on Mar 12, 2023 at 00:39 UTC
    I'm confused, unstable specifications result in an unstable project.

    This can happen if communication is bad or priorities are messed up.

    Starting with demos, POCs and tests for the main features should minimize that risk.

    With some clients this still happens, but then it's their responsibility to pay for the extra costs.

    Cheers Rolf
    (addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)
    Wikisyntax for the Monastery

      I guess I'm not communicating my point clearly. I don't see any point in writing tests for a first draft of a spec implementation/POC. No client is going to communicate their requirements in a manner that's not going to require iteration on both ends unless they're coming to you saying "we need to integrate with this API" which is an existing specification that has known inputs and outputs regardless of the quality of the API. POC and demos have only as good of a chance of being correct as the requirements dictating their implementation and the quality of communication to do so.

      Starting with demos, POCs and tests for the main features should minimize that risk.

      I'm not sure how tests minimize risk in a POC unless you're using them as something that's black and white in terms of an API contract that says "hey these are the requirements that were communicated and this is proof that they were coded to spec." I feel like it's much harder to iterate into a concrete state quickly if you have to change tests 2-3 times before you and your client reach a consensus.

      Anyway I'm probably not going to get my point across any more effectively at this point so hopefully someone finds some sort of value reading through this.

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

        I have an anecdote about writing tests.

        At my $job-2, my "dotted-line manager" got angry at me because I was spending time writing tests instead of implementing the feature he wanted me to implement. I completed both the tests and the feature one day before the deadline, and you've probably already guessed what happened on the deadline day: the specification changed. Without the tests, I would have been lost. It was pretty easy to fix the tests, and with the tests for the new specification, I was able to fix the code, too, and be confident that the change was correct. YMMV, but for me it was eye-opening.

        map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]