Read on Twitter
When do you write unit tests?
- Before implementation?
- During implementation?
- Right after implementation?
- When something breaks?
TDD instructs you to write your tests before implementation but I don’t always agree.
And here’s why
A not-so-mini
- Before implementation?
- During implementation?
- Right after implementation?
- When something breaks?
TDD instructs you to write your tests before implementation but I don’t always agree.
And here’s why
A not-so-mini
I feel that it’s almost impossible to know the complexity of your code before implementing.
You may realize mid-implementation of a need to further abstract.
This may be from further extending and encapsulating from the base interface object.
You won’t know beforehand.
2/
You may realize mid-implementation of a need to further abstract.
This may be from further extending and encapsulating from the base interface object.
You won’t know beforehand.
2/
Now you should have your functions performing one job and one job only.
This will help keep your tests functional.
But what if you need to change the signature of a base function?
The one-job function is so much easier to test the new parameters or return object.
3/
This will help keep your tests functional.
But what if you need to change the signature of a base function?
The one-job function is so much easier to test the new parameters or return object.
3/
So I think having unit testing in mind before implementation is important.
But writing them is a work in progress as your code changes.
So a semi-TDD approach, if you will.
But I really cannot stress enough to only test one behavior at a time.
4/
But writing them is a work in progress as your code changes.
So a semi-TDD approach, if you will.
But I really cannot stress enough to only test one behavior at a time.
4/
I advocate for more unit tests to cover more logic rather than complex tests covering multiple points.
Testing this way let’s you make small changes to your tests as you change your logic.
So I write simple tests before implementing then keep adding as my code evolves.
5/
Testing this way let’s you make small changes to your tests as you change your logic.
So I write simple tests before implementing then keep adding as my code evolves.
5/
The main point I want to make in this thread is to test throughout your implementation.
Start early, start simple, extend.
Do not overcomplicate.
Test focused and test often.
But for the love of god, do not wait to test until something breaks.
6/
Start early, start simple, extend.
Do not overcomplicate.
Test focused and test often.
But for the love of god, do not wait to test until something breaks.
6/
