Why TDD?

  1. from Alex to Bob
  2. in the current financial year (1st Apr — 31st Mar)
  3. and are more than 1000 shares at a time.
(txn.getDateOfTransaction().isEqual(financialYearStartDate) ||
txn.getDateOfTransaction().isAfter(financialYearStartDate)) &&
(txn.getDateOfTransaction().isEqual(financialYearEndDate) ||
txn.getDateOfTransaction().isBefore(financialYearEndDate))

The first and foremost reason you write unit tests is to reduce the feedback cycle.

The second reason why tests help. Checking Edge cases is simple with unit tests.

// change txn.getNumberOfShares() > 1000 totxn.getNumberOfShares() >= 1000

This is the third reason why tests help. It helps determine if there are other parts of your code that might break because of your code change.

This is the fourth reason why tests help. Refactoring safety. Reduces the fear of changing your code. If you fear touching your code, that project is doomed cause change is the only constant. Everyone knows that.

This is the fifth reason why tests help. Tests serve as living documentation of your code. You can also write all your acceptance criteria as tests like above.

  1. Remember the first reason? Reduce the feedback cycle. Ensuring you have a test before you code, will give you the chance to validate your code immediately after you write it.
  2. You want to refactor that code now? You are covered. Go for it. You already have a test for it which you know will break in case you do something wrong.
  3. You write your code first, you might or might not go back and write a test for that code you just wrote. We are all human. When we have already written our logic, the chances are, you are only going to write just enough tests to keep the coverage detector happy. One happy test case and I am out of there! Thats not going to cut it. The negative tests might not work. You have not considered all scenarios in which your code might be called.
  4. Have you heard of YAGNI? You aren’t gonna need it! How many times have you written a lot of code only to throw it away in the end cause actually that was not what was required in the first place! Writing a test before you wrote so much code, would help stop the madness.

The basic steps of TDD are easy to learn, but the mindset takes a while to sink in. Until it does, TDD will likely seem clumsy, slow and awkward. Give yourself two or three months of full time TDD use to adjust.

--

--

--

I work as a software developer. I love pecking away on a keyboard coding.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Agile Product Development as a small software development company?

How You Can Become a Better Developer

Female software developer coding

Make Sure Scrum Fits your Purpose, not Vice Versa. Part 3

Flutter Design Patterns: 18 — Builder

Kestra 0.4 release, Performance & Kafka, JDBC and Singer plugins

Running spark application jobs(actions) parallel with FAIR scheduler

Analyzing Cloudflare Logs with AWS Athena

Prize raffle for the Buy&Hold contest is closed.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sethu

Sethu

I work as a software developer. I love pecking away on a keyboard coding.

More from Medium

Write less but clean quality code.

Generating end user and developer documentation

Common traps in development