A management AntiPattern wherein it is decreed (due to the usual schedule or budget pressures) that testing of the product will be rather limited in scope (or in the extreme case, not done at all); yet a high-quality product is expected.  The rationale for this apparent disconnect is the belief that quality should be ''free''--a natural byproduct of development methodologies (see QualityIsNotFree for more on this); and programmers who write buggy code simply are bad programmers.  This is an AntiPattern because:

* The main mechanism for programmers to ''produce'' quality code is--testing.  Formal methods and ProofOfCorrectness techniques have not advanced to the point where they are suitable for use in many programming tasks--and even then, these techniques still require iron-clad requirements specifications to verify the implementation against.  
* Programmers (good ones, at least) will invariably do testing anyway; they just might not tell you about it.  (A not unreasonable position to take; when I give the ProjectManager estimates; I don't break it down into time spent editing, compiling, linking, etc... why would I segregate out the UnitTest''''''s?)
** However, final acceptance testing (including integration testing) may be compromised.  Some methodologies eschew or minimize this; but in my experience it is still important.  
* Testing may be seen as overhead to be eliminated.  Part of this belief may be carryover from manufacturing, where fellows like WilliamEdwardsDeming and Crosby have shown that controlling processes to eliminate spoilage from being produced is more efficient in many cases then testing to detect it later (QualityIsFree).  How much this observation (made in the context of the controllable and deterministic processes of a factory) applies to the creative and non-operational processes used in software design and implementation, is questionable.
** ''Isn't testing how developers prevent spoilage from being produced? Is there a better way?''
*** In the manufacturing process, improved process control is used to prevent spoilage.  Many development methodolodies have tried to become an analog to process control in the software development realm, with far less success than we would like.  
----
In a job interview I was asked how I would respond to a developer that asked "Why do you write tests? Just write code with no bugs."  I floundered and eventually said "I'd need to go away and think about that one." It's a week later, and I knew the answer all along - it just took me a while to come up with it. Here's my answer:

Maybe you can write perfect code, but over the lifetime of your code it's going to be looked at, and modified by, and copied by, many far lesser programmers. They will introduce bugs, because they can't write perfect code; your tests will help catch those bugs, and stop them going live. Further than that, you're making an invalid assumption: Testing is not (just) to catch bugs. People who do test-first development are being continually forced to answer the questions "What does this class do", "How will this class be used" and "Do I really need this class anyway". Such questions are extremely valuable to system design and so test first developers end up with more modular code, with better metrics for coupling and coherence, with greater maintainability. Oh, and fewer bugs.

Now, can I wind the clock back a week so I can give this answer in my interview..?  --StuartScott

I'd reply, "How does one write code with no bugs?"  ''Well, it's clearly a ridiculous position to take. But when you're trying to win business, and also to build relationships with your customers, then you need to avoid the ego bruising response of "Don't be daft!"'''