|
in reply to Needing help on testing
Hello Zenzizenzizenzic and welcome to the monastery and to the wonderful world of Perl!
In my little experience, the short answer is: no, there is no an easy way to test code not contained in modules.
You can use IPC::Run3 to test your perl script, but you'll find soon that will be not an easy path. If your programs are interactive ones will be not easy at all.
My humble suggestion is to start familiarizing with tests testing your 20% of codebase that's already in modules, then identify which part of the codebase are critical and try to abstract their functionality in modules and write tests while coding your modules, not after.
You can also explore the Modulino (see it at mastering perl by brian d foy) tecnique that use caller You'll wrap all the code in a script into a main sub and you'll use main() if not caller(); see also this article at perlmaven.
See Rescue-legacy-code-with-modulinos too
Also some link on my bibliotheca can be worth to read.
L*
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
|
Re^2: Needing help on testing
by AnomalousMonk (Archbishop) on Oct 30, 2018 at 00:25 UTC
|
... there is no an easy way to test code not contained in modules.
Zenzizenzizenzic: And in general, there's no easy way to test code in a situation in which you've developed a shitload of code and then, and only then, started to think about how you're going to test it all. Let this be an object lesson to all padawans. (I even know of organizations where design and development of the testing environment begins at the same time as — or even well before — application development.)
Give a man a fish: <%-{-{-{-<
| [reply]
[d/l] |
|
|
| [reply]
[d/l] |
|
|
| [reply]
[d/l] |
|
|
|
|
"I even know of organizations where design and development of the testing environment begins at the same time as — or even well before — application development."
This is personally how I approach nearly each piece of software I write (whether it be Perl, Python, C, C# etc), and most of my code has 98%+ coverage (with coverage being covered in dozens if not hundreds of different angles).
That said, the vast majority of companies I've worked for or contracted for don't take this approach as it's too costly. Businesses need to get product out the door, so proper Test Driven Development (TDD) adds a massive delay to realizing Return on Investment so it's mostly eschewed for develop it now, hope it works, but if we have to fix a bug later, THEN add tests for that one piece.
It's a sad reality that profits outweigh quality, but that is the world we live in, unfortunately.
Now, if you know of a specific shop that does use TDD by default, please let me know who :)
| [reply] |
|
|
…it's too costly.
It’s a false economy though. Maybe not 100% but usually if there is some balance between total coverage TDD and shipping early/often. Like buying something on credit with a large downpayment, you halved, at least, the total cost when the interest is paid off. You, in my view, take the right approach and I expect the hackers who work with you or inherit your code appreciate it. That said, “profit” is not a dirty word. Without profit, there is nothing to bank. Without savings banked, we’re back to toiling in the fields or on the seas and hoping the larder doesn’t turn before the spring.
| [reply] |
|
|
I even know of organizations where design and development of the testing environment begins at the same time as — or even well before — application development.
Those are the ones that never finished their original project, because they spent all the time debugging their tests that have been written by the same people as the actual project code.
perl -e 'use MIME::Base64; print decode_base64("4pmsIE5ldmVyIGdvbm5hIGdpdmUgeW91IHVwCiAgTmV2ZXIgZ29ubmEgbGV0IHlvdSBkb3duLi4uIOKZqwo=");'
| [reply]
[d/l] |
|
|
That's not true, actually. At work, we write lots of tests: unit tests, integration tests, and API tests, we have manual testers and QA engineers. Maybe it wasn't the case at the very beginning, but nowadays, any new feature or change must be properly tested. And our original project is kind of finished, or at least our customers pay for it and use it (we've just had the best quarter results in the whole history).
($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
| [reply]
[d/l] |
|
|
I also write a lot of tests. Sometimes before a new feature. It does take quite a bit of time; more time than the actual code in most cases. It also protects against shipping bugs, losing customers, late night emergency patches, the next dev’s insanity, regressions, bad upgrades, doc errors, impossible refactoring time…; and in my current $work industry in particular, it prevents lawsuits. After a year or so, it has amply repaid the initial time sink.
| [reply] |
|
|
We're getting a couple new programers soon, so I'd like to be able to teach them "right" vs. "the way we've always done it".
| [reply] |
|
|
