Test Driven Development

A software development process where the tests are written alongside the actual code
TDD is not writing the tests first, it is development driven by the tests

Breach of specification scope
- You may have written more code than needed fulfilling requirements that are not in scope of the given specification
The developers may not have fulfilled the specification
- May have written too little code and missed some requirements of the specification
Potential regressions introduced
- At any point in the development you may have caused a regression to part of the code without even knowing it, this could have been on a refactor or when implementing new behavior
Difficult to test behaviour is ignored
- Behavior that is difficult to test is ignored

The TDD process follows an iterative cycle which contains the following steps
RED: Write a failing test
- This means only write the minimum to test that specific behavior outlined in your specification
GREEN: Pass the test
- Write the minimum amount of code required to pass that test
REFACTOR: Refactor the code written

Experienced or senior developers do not need to write tests
- Everyone is prone to making mistakes
- Tests reveal edge cases
- Test are the specification that your code must fulfil
Overhead of writing tests could be spent on writing the code
- TDD actually improved the longevity of the code base and sustained productivity over time. This is because writing without the test leads to regressions that will not be picked up until much later on in the development and at this point, your software may be out in production or will have to be fixed on a new ticket, when this all could have been avoided in the first place
- Tests pinpoint exactly in the code a failure occurred and without the tests being written along existing functionality on a regression it is very hard to find where the failure occurred
Lack of testing culture within your company
- This is an excuse
- As developers it is our job to uphold standards independently even when our co workers do not. Lead by example and maybe that junior or even senior dev neglecting testing will take notice and follow in your footsteps.

If you are asked to build something from someone in a non technical way, you must break this down into a technical spec. Before you even write tests write a few short comments describing how your software should work (inputs, outputs, what happens given invalid data, is your function curried) all of these are valid thoughts before writing tests. Its not good enough to write test only for valid input
Test should be cohesive, only test a small part of the code or one behavior. This is because we want to be able to pinpoint exactly where in the code it failed
It may be obvious to you now, but not to future you or other developers
Test should run independently. False positives and False negatives. If a test case fails because of another test case you may be lead astray by this test
Test for edge cases. Make sure you test the bounds of your program, test should be thorough
Tests should run fast. If tests do not run quickly they will not be run often