Software engineering isn’t only about code. It’s engineering

TDD need not be a big deal. It can seem cubersome but there are mindsets and tools that can make transition smoother.

TDD is shown to reduce defectsby a large margin. Tests will save you time in the long run.

There are my initial thoughts on test driven development.

Why TDD?

If you are doing TDD, you do not need to setup and interact external systems before implementation.1 You can use their mocks.

Both tests and code is cleaner and precise.

The Three Laws of TDD

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

How to TDD?

  1. Assume the test will work properly, what is the minimum test? Write that test.
  2. Fix compilation errors if any. 1
  3. Write minimum code required to pass the test.
  4. Run all the tests
  5. Iterate

Making TDD easier

Usually TDD can be cumbersome because:

  1. Testing is extra code
  2. You have to switch between current code and tests
  3. you have to rerun tests
  4. No one does it


1. TDD is a todo list of feature to do

By writing test first, you get clear on what you want to implement. This leads to better design.

2. Switch between testing and code easily

In intellij press Ctrl + Shift + T for vs code :

3. Rerun tests automatically

On local: have tests run automatically after each save

Given when tehn Search for libraries that make easier to test

4. No one does it

Yeah. It takes times to learn. TDD/any development practice is easier when whole company is aiming at it or enforcing it.


write experimental/learning code in a separate project. but always write production code with TDD.

fast feedback

find fastest and tighest feedback

TDD leads to fast feedback

to refactor you need really good tests

seeing a test fail is a test that feature is not implemented. sometimes it may happen that the new test passes which means the feature is already implemented and you had forgotten to assert it. or your system is not working properly.

“I don’t know what I am going to build” business? -> ask them for clarificaiton logic -> get away from screen and plan properly side effect -> read documentation. write a lot of little program. repl command line interface to test/learn libraries. jshell?

// it’s hard to decide what to test when you are writing tests later if you write tests later, you do it for what is working.

TDD only that much functionality and nothing more only test what’s within the class. not outside it [ANkush]

mentally it can be worth thinking as red green refactor as checklist

refactoring while doing tdd

read the tests first

// it’s hard to decide what to test when you are writing tests later if you write tests later, you do it for what is working.

ATDD: THe team decides acceptance criteria first before implementing acceptance criteria should be defined well for each story. Tips: