Why I chose to do TDD for my new side project

This post is more of a continuation to this tweet One thing which I tried doing differently this time with one of my side projects is to do TDD from the start. Someone may ask why? It's just a side project no? (1/n) — Tasdik Rahman (@tasdikrahman) October 4, 2020 I have been building bhola in my free time, and one thing which I tried doing differently this time with it, was to practice TDD from the start. ...

October 7, 2020 · 7 min · Tasdik Rahman

F.I.R.S.T principles of testing

First principles of testing stand for Fast Isolated/Independent Repeatable Self-validating thorough Bugs are introduced in the parts of code, which we usually don’t pay attention to, or places which are too hard to understand. Fast The developer shouldn’t hesitate to run the run the unit tests at any point of their development cycle, even if there are thousands of unit tests. They should run and show you the desired output in a matter of seconds ...

March 13, 2019 · 2 min · Tasdik Rahman

What should and should not be tested in unit tests?

I have written about F.I.R.S.T principles of testing and TDD as a school of thought Probably an extreme opinion, but this is how Jeff Atwood puts it I Pity The Fool Who Doesn’t Write Unit Tests But what should you test? This I generally try to follow Test the common case of everything you can. This will tell you when that code breaks after you make some change (which is, in my opinion, the single greatest benefit of automated unit testing). Test the edge cases of a few unusually complex code that you think will probably have errors. Whenever you find a bug, write a test case to cover it before fixing it Add edge-case tests to less critical code whenever someone has time to kill. This will not only help you deliver and release faster, but will also make you more confident about your own codebase. ...

March 13, 2019 · 2 min · Tasdik Rahman

Test-driven development as a school of thought

Software is eating the world, and so is the world of software development constantly changing. One way of developing a project would involve analysts figuring out the business requirements and sit for a few weeks if not months these requirements would be given out to the architects who would in case break the problem down into manageable chunks the chunks themselves would be then given out to the teams which would be the delivering the specific modules. Nothing, but a typical waterfall model scenario, coming with it’s obvious pros and cons. ...

February 8, 2019 · 3 min · Tasdik Rahman