Re^6: What to test in a new module

I think there is a chicken-and-egg problem in this discussion and you all are talking about different layers of tests.

When designing an API is beneficial to write demo usage code. Like the synopsis part in a CPAN module. These can be tested against proof of concepts. That's the nucleus of the project.

When adjusting the spec you need to adjust those demos, hence code and test suite grow in the process.

After those are sufficiently stable you start wiring the POCs into modules with more specific unit tests, for instanceto cover edge cases.

But the tests you wrote while designing the API are already there.

You may have decided to change the internal architecture in the middle and split the code into multiple dependend modules behind the API. Different modules will have different unit test suites.

For me it's an iterative process, but this first layer of API tests will stay quite stable while the POCs will only be kept for historical reasons.

These API tests are the first tiny eggs if you want...

Cheers Rolf
_{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)

Wikisyntax for the Monastery}

Comment on Re^6: What to test in a new module

Replies are listed 'Best First'.
Re^7: What to test in a new module by stonecolddevin (Parson) on Mar 11, 2023 at 20:37 UTC
I guess I'm just not really a fan of throwaway tests. It sounds like like you're either assuming the demos are stable or are writing throwaway tests and don't mind the churn. Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past	[reply]
Re^8: What to test in a new module by LanX (Saint) on Mar 11, 2023 at 21:37 UTC
I'm not sure where you read that I was advocating throw away tests. My point was it's a top-down process with different layers of tests and POC. The API tests of the top layer are stable, the POCs less so. There is no point in starting a long endeavor without clarifying the clients expectations proving the feasibility This is best done with some demo code, and this can and should be tested. Written specifications are open for interpretations, tests let you sleep well. Since those tests define your API they can't easily be thrown away anymore unless your POCs were bad. Hope my perspective is clearer now. Cheers Rolf _{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^9: What to test in a new module by stonecolddevin (Parson) on Mar 11, 2023 at 22:15 UTC
Yea again this assumes your demo code proves to be correct on the first swing, and I can count on one hand I've seen that happen. I honestly don't see the point in writing tests for demo/poc code until you and the client are in agreement that the current stage looks correct. Changes after that are changes in scope and will probably require tests to be reworked anyway. How do you know your top level API tests are stable? How do you know they're going to stay that way? Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past	[reply]
Re^10: What to test in a new module by LanX (Saint) on Mar 11, 2023 at 22:24 UTC
Re^11: What to test in a new module by stonecolddevin (Parson) on Mar 11, 2023 at 22:33 UTC
Some notes below your chosen depth have not been shown here


We don't bite newbies here... much
	PerlMonks