Having an idea of writing a test & make it work quickly, does not look intuitive for a good software engineering approach.

You're likely not interpreting this the way it was intended.

"writing a test & make it work quickly and then never touch or improve it again" is a bad software engineering approach. But the resource you're quoting never said that you shouldn't refactor, it just said to keep it simple when you're still on the stage of getting it to work (i.e. getting a test to turn green).

For a given requirement, a simple solution design that make us think about creating good abstractions and then Implement with testing looks very intuitive.

The intention is good but you're forgetting about the drawbacks. Taking a "design first, implement second, test third" approach is susceptible to two major issues:

• Overengineering (designs that are more complex than they needed to be)
• Wasted implementation effort (when the tests show you were doing something wrong)

The red/green approach inverts that order of operations, so that you can better avoid these weak spots.

1. Write a test which compiles but fails.
2. Implement a quick and dirty solution until the test succeeds.
3. Improve upon that solution (refactoring) while making sure that the test doesn't start failing again.

This prevents the weaknesses mentioned before:

• You're less likely to overengineer as you have concrete evidence on exactly how complex your implementation is (rather than guessing what it will be), so you can better tailor your design to your implementation
• Since you can run your test every step of the way, any mistake you make is immediately noticed, and you don't find out about it much later in the process.

Is TDD a brain wash?

No, but it does shake up the fundamental approach to software development. If you cling to the (non-TDD) fundamentals you know and love, then you're not in the right mindset to accept TDD as different-but-valid.

Why would a good Software engineer, make the test work quickly, committing whatever sins necessary in process?

Because that software engineer minimizes time wastage while maintaining code quality.

By keeping the implement/test feedback loop as short as possible, they maximize their efficiency at finding and dealing with any error they may have made as the error would have been made recently (as opposed to a long time ago, where your memory is fuzzier).

Why would the refactor stage be applied after completing a dumb green stage?

By implementing a first (temporary, working) solution, they more concretely define the domain for which they will then design an appropriate second (cleaner, more abstracted) solution), thus making sure they don't overengineer things or regress constantly, both of which waste time on things that are not necessary or can be avoided.

Are those test cases(in Red stage) missing in non-TDD approach?

Red stage test cases are there for two things:

• They help you define an interface without being distracted by the implementation of that interface.
• You set up a testing suite that will then support your implementation and refactoring stages, which means you get more direct and accurate feedback about the consequences of any changes you make. Think of it like having a personal code reviewer who's constantly looking over your shoulder and immediately pointing out any mistakes you make, instead of telling you a week later.

For a given requirement, a simple solution design that make us think about creating good abstractions and then Implement with testing looks very intuitive.

The design phase is comprised of two main considerations:

• Separating the interface from the implementation, by abstracting an interface that focuses on communicating with the outside world.
• Design patterns that streamline the internal implementation.

I want to draw your attention to the first bullet point I listed for the red stage test cases.
By forcing a developer to write tests based on an interface without an implementation, the developer is forced to design the interface in a pure manner (without knowing any implementation details, since that stage hasn't happened yet).

This already covers the first bullet point, separating the interface from the implementation. It's beneficial to do this before the implementation stage, as it means that you're not distracted by having implementation knowledge that you shouldn't be relying on when defining the interface.

The second bullet point, implementing design patterns to streamline the internal code, should only occur when there is internal code (i.e. after the implementation stage), since the choice of design pattern completely depends on the actual code being used. Here, you should rely on implementation knowledge, which is why the abstraction stage comes after the implementation stage.