|
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] |