Re^6: Developing a module, how do you do it ?

I've seen people go to extraordinary steps to satisfy the coverage tools need to have every code path exercised, even when many of those codepaths are for exceptional conditions that are near impossible to fabricate because they are extremely rare ("exceptional") conditions. Hence you have a raft of Mock-this and Mock-that tools to "simulate" those failures.

I agree, but don't replace crazy with crazy.

Write tests that provide value. Use coverage to see if you've missed anything you care about. Think about what that coverage means (all it tells you is that your test suite somehow executed an expression, not that you tested it exhaustively).

If you're not getting value out of these activities, you're probably doing something wrong. That could mean fragile tests or tests for the wrong thing. That could mean that you have a problem with your design. That could mean too much coupling between tests and code or too little (and too much mocking).

There's no substitute for understanding what you're doing, so understand what you're doing.

(But don't resolve never to use a lathe or a drill press because you heard someone once used one somewhere for eeeeeevil.)

Comment on Re^6: Developing a module, how do you do it ?

Replies are listed 'Best First'.
Re^7: Developing a module, how do you do it ? by BrowserUk (Patriarch) on Mar 03, 2012 at 04:28 UTC
There's no substitute for understanding what you're doing, so understand what you're doing. (But don't resolve never to use a lathe or a drill press because you heard someone once used one somewhere for eeeeeevil.) I utterly agree with both those statements. Unfortunately, understanding takes time and practice and a few different projects and types of project, before the patterns from which understanding forms become evident. As a substitute, society tries to teach experience; but that is a very hard thing to do. So, you end up with guidelines that omit the reasoning, and so become unassailable dogmas. Hence, I received a recruiter circular a few months back that asked for "Perl programmer experienced in coding to PBP/PerlCritic standards." (Really. Honestly. I just checked to see if it was still hanging around in my email somewhere but it isn't :( ) With respect to coverage tools. If a module is big enough that I need a computer program to tell me if I've covered it sufficiently with tests, it is big enough that it will be impossible for a human being to get a clear enough overview to be able to successfully maintain it. It is therefore too damn big. But then, for any given problem I tend to write about 1/10 of the code that the average programmer seems to write. Mostly because of the code I don't write. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]

Replies are listed 'Best First'.

Re^7: Developing a module, how do you do it ?
by BrowserUk (Patriarch) on Mar 03, 2012 at 04:28 UTC

There's no substitute for understanding what you're doing, so understand what you're doing.
(But don't resolve never to use a lathe or a drill press because you heard someone once used one somewhere for eeeeeevil.)

I utterly agree with both those statements.

Unfortunately, understanding takes time and practice and a few different projects and types of project, before the patterns from which understanding forms become evident. As a substitute, society tries to teach experience; but that is a very hard thing to do. So, you end up with guidelines that omit the reasoning, and so become unassailable dogmas. Hence, I received a recruiter circular a few months back that asked for "Perl programmer experienced in coding to PBP/PerlCritic standards."

(Really. Honestly. I just checked to see if it was still hanging around in my email somewhere but it isn't :( )

With respect to coverage tools. If a module is big enough that I need a computer program to tell me if I've covered it sufficiently with tests, it is big enough that it will be impossible for a human being to get a clear enough overview to be able to successfully maintain it. It is therefore too damn big.

But then, for any given problem I tend to write about 1/10 of the code that the average programmer seems to write. Mostly because of the code I don't write.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

[reply]