For me, "train as you fight" shows up mostly as a t directory. When I am good about this (and I am not always that good), I at least create tests to ensure the code compiles and the pod is valid. When I get over that little hump, adding other tests is easy: I already have the t directory and am using "make test".

I'm still to be, and don't expect to be, convinced of the value of \t directory and Test:* modules.

Don't misread that. I'm strong on tests and testing. It is the only tool short of suck-it-and-see that we yet have for trying to establish the quality of the code we produce.

The problem with those modules and the \t directory is that they rely on tests external to the code. Out of site, out of mind. Tests should be integral with the code where they may be maintained along with the code. You can have all the tests in the world but if they are testing the wrong things they are little more than overhead.

In an ideal world, the tests would be generated automatically by the compiler thereby removing the possibility of the tests and the code becoming out of sync, but that is still a ways off.

Design by contract shows great potential (IMO). I had hoped that something similar would be integral to P6, but I haven't seen any signs of it. I'm hoping that the (proper) macro facility will allow this to be added in fairly short shrift after the fact. Time will tell.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

DBC is integral to Perl 6. If you google for "design by contract apocalypse perl", you'll discover that it's even been mentioned in discussions here on PM.

The problem with those modules and the \t directory is that they rely on tests external to the code. Out of site, out of mind. Tests should be integral with the code where they may be maintained along with the code

Test::Inline?

You also might find the idea of Zero Button Testing appealing.

Personally, I find having the code and the tests in the same document gets in the way of reading the code and interferes with refactoring, but YMMV.

You can have all the tests in the world but if they are testing the wrong things they are little more than overhead.

Doctor, it hurts when I do that :-)

In an ideal world, the tests would be generated automatically by the compiler thereby removing the possibility of the tests and the code becoming out of sync, but that is still a ways off.

I see people asking for this sort of functionality a lot and it confuses me. I must be misunderstanding what you mean since, on the face of it, what you're requesting seems to be impossible. How would the magic test producer know what the code should do.

Design by contract shows great potential (IMO)

Interestingly enough DBC used to be my preferred design methodology, before I discovered TDD (Eiffel is still one of my favourite languages). Because you're dealing with concrete data rather than an abstract contract I find it much easier to incrementally develop code with tests.

With respect, the complete maxim was taught to me as "Train as you fight, fight as you train." If you expect to engage in combat in full chemical protective gear, you must train in full chemical protective gear. If your training prescribes that you must use a checklist to launch the alert fighter, then you must use the checklist when the klaxon goes off.

Relate this to programming:

• Your program, application, or system must pass security certification and accreditation. So don't build your work with hard-coded, plain-text passwords.
• Your work is going to have to meet the standards of Sarbanes-Oxley, plan for it and program accordingly.
• QA testers are going to evaluate your work against requirements, write code that satisfies requirements.

For those of you old enough to remember Sgt Rock and his Howlin' Commandos, "Nuff said"

Hm. I don't think the analogy holds very well.

If you expect to engage in combat in full chemical protective gear, you must train in full chemical protective gear.

Not all fighting is done wearing NBC suits, and as sure as hell, not all training is. Sure, they train under those conditions so as to have experienced them, but I doubt it makes up more than 2 or 3% of their total.

Security.

The app I wrote to index the ingredients in my sisters recipes has hard coded credentials. If hackers crack it, I hope they enjoy her profiterole recipe as much as I do.

Choosing what to not to expend effort securing is as important as securing those things need it.

I'd be interested to hear your solution to the problem of supplying credentials to your DB apps? (Assuming that they can't be entered manually every time. Eg. Web apps?)

Sarbanes-Oxley

Doesn't affect me (note my handle). But from what I scanned on wikipedia, it probably rarely affects programmers in general, being aimed at corporate/legal processes rather than programming in general. I can see how for example it might be desirable to have an MIS suite provide hooks for auditing, but a good auditor would probably ignore that on the basis that they can be as bogus as the glossy company brochure.

Requirements

Can't argue directly against what you say, but I see little correspondance between that and military practices and doctrines.

Then again, maybe I can argue against it. Requirements (and plans) are a fine starting point, but in all but the most repetitious of projects, they change. In common parlance, "the best laid plans of mice and men", or as the military would have it. "No plan survives the first encounter with the enemy."

---

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."