That is your prerogative. However that doesn’t change the fact that many organizations, especially smaller ones, proclaimed we don’t have time for testing before Extreme Programming coined the term Test-Driven Design. Testing was often delayed to user acceptance testing at which point in time defects were layered upon defects. Fixing defects later usually costs more time and money and that is waste.

People rarely have the discipline to go back to build tests around code they already believe to be working (and verify that the test will in fact detect a defect) - because they could be writing more code for production instead.

So when I read

time to deliver my project is less as writing test and design code pieces could be time taking.

What I see:

• We barely have enough time to develop the product if even everything goes according to plan and every decision made is the right one.
• We need to start generating “product code” immediately so there is little time “think about it” (i.e. design).
• We have no time to write code for tests as we barely have enough time to code the (right) product.

which is a recipe for disaster. So yes, I actually believe that the opening post is seeking to legitimize minimizing and potentially completely eliminating any automated testing effort - it’s not just about TDD.

For me TDD is about product code always having automated, executable tests that documents it’s behaviour, creating the opportunity to refactor without hesitation. I personally don’t care if the tests are written first - but they have to be red first. And in my opinion heavy use of sophisticated mocking libraries is a smell. Your tests are telling you:

• Your code structure is suboptimal
• Your boundary is in the wrong place
• Implementation details are leaking through the boundary
• The test is in the wrong place

In reference to Chad Fowler: “Tests are a design smell” is meant to be a provocative statement towards a community which glorifies 100% test coverage.

Don’t let your tests be an anchor and maybe it’s more important to monitor the runtime behaviour of your code than it is to test it.

i.e. it’s about balance:

• static type checking doesn’t replace testing
• tests can’t replace runtime monitoring
• some scenarios are too costly to test - provided the manifestation of a defect in production is largely inconsequential, will be quickly noticed and will be quickly addressed and rectified.

Also he talks about ‘Code “this big”’, i.e. code that is small enough to be replaced wholesale. After a rewrite, how do you know it is “mostly safe” to deploy the rewritten code to production? The approach strongly suggests the existence of a test harness emulating the real operating environment that can run tests (scenarios) against the rewritten code. I.e. the tests only verify the correct behaviour of the “component” and are isolated via the constraints imposed by the operating environment.

I can understand the cynicism that you project towards certain consultants and consultancies that market TDD/BDD as some kind of easy street cure all (once again focusing more on process than intent) but one shouldn’t “throw the baby out with the bathwater” and more importantly not let it become an excuse to cut back on essential testing activities (not implying that you were suggesting that - but in this topic I think there is a very real danger of that interpretation).

Testing isn’t easy and good testing doesn’t “come naturally”.

I think it is important to remember that “novices” want hard and fast rules because they’re easy. “It depends” while usually appropriate isn’t exactly helpful from a novice’s perspective. Dogma via “Development by Slogan” be it DRY, TDD/BDD, etc. can be a real problem.

Tests restrict/slow down redesigning of the system which in these cases is vitally important to be able to quickly do.

This one is a bit of a slippery slope - we’ve all done it. But again context determines the risks we are taking in doing so. In some circumstances the risks are low enough but in others designing your tests (scenarios) is designing your software.

(c. f. gherkin, it is super cool )

For me the Cucumber thing seems to be moving back into the tool-addiction of Rational ClearCase/Big Design Up Front - so if I was looking for waste I would start right there.

I would probably not do Test-first development when there are strict deadlines

Statements like this are dangerous because they will be construed by outsiders and novices that TDD in particular and testing in general is inefficient and expendable/optional. It is intuitive that you will save time now if you don’t create the test right now. It is counterintuitive how much more expensive many defects will get the longer they remain in the codebase.

That is likely a reflection of the size of the projects. The flip side is that while it may feel like overkill to use testing tools on smaller projects, it’s the perfect time to become accustomed with them before you embark on a larger project. Tests are also a feedback mechanism - if it’s hard to write a test then there may be a problem with your design. The worst thing is if you have to introduce testing after the fact, especially if there was no other incentive to decouple in all the right places.

As usual, opinions vary.
Is TDD Dead?
Test-Induced Design Damage. Fallacy or Reality?

Managing the Development of Large Software Systems (1970) i.e. “the Waterfall Paper”. Figure 2 shows “ideal waterfall” - figures 3 and 4 acknowledge the realities, i.e. iterations will happen - which is acknowledged 16 years later in A Spiral Model of Software Development Enhancement (1986).

Ultimately to “reduce waste” you need to tighten the feedback loops; 1) allow the customer to discover as early as possible what they actually need rather than what they think they want; 2) be notified that you are breaking important things when you are making changes.

Bonus:
GOTO 2017 • Engineering You • Martin Thompson
Quotes from the Nato Software Engineering Conference in 1968
Proceedings of the Nato Software Engineering conference in 1968

A software system can best be designed if the testing is interlaced with the design instead of being used after the design.
Alan J. Perlis (1968)

I would like to add to this discussion that I have a feeling that a lot of the quoted/cited statements are interpreted as a rigid ‘gospel law’ rather than a guideline whose exact rigidity and details depend on where it is used.

Dont make choices based on what someone else said about the situation they were in, but based on a comparison you make between the situation they were in and the situation you are in.

Personally, I do not write tests during a hackathon with a strict deadline. I do not write tests when creating a Proof-of-Concept. Tests restrict/slow down redesigning of the system which in these cases is vitally important to be able to quickly do.
I do write tests once a system is approaching a presumed ‘stable’ state, mostly to prevent regressions in the future. A certain dose of regression tests are also really good to keep your code from breaking functionality when working together with multiple people.

I do write feature/integration tests when requiring to follow a strict set of specifications/requirements (c. f. gherkin, it is super cool ); mostly to be able to agree with the other party about the details of the specification exactly.

I write unit tests mostly as doctests to explain, in a library or business logic code, to other devs (and, importantly, myself) how stuff works and fits together. This is also the main place where I sometimes work test-first, when I already know how I want something to look but have yet to write the implementation.

I write rigorous tests and possibly type-proofs if (and only if) writing important systems that are vitally important (like when a crash would be life-threatening or cost thousands of dollars) or when the system will be impossible to change in the future (like when writing Smart Contracts).

There is no silver bullet in choosing a testing methodology. It really depends on what you are doing. To answer the original question: I would probably not do Test-first development when there are strict deadlines,( but maybe I would based on other requirements of the project).

Oh, and as a side note: avoiding strict deadlines will probably improve the quality of your applications. Of course, educating managers is hard .

I think you will get different answers from different people at the end of the day you have to do what’s right for you. However perhaps answering this question might help:

• Is the project expected to grow fairly large? Is adding new features and maintainability going to be important? If so, I think that’s a good case for writing tests.

If the project is small, or once created unlikely to change much and you need to get it done asap, then maybe testing isn’t quite as important..