It’s certainly been a while since my last post. I’ve been slacking way too hard, especially with break, but now it’s time to lock in and focus on my work.
For this blog post, I’ll be talking about Test Driven Development, or TDD for short. TDD is a “software development practice that focuses on creating unit test cases before developing the actual code.” It attempts to avoid or solve the issues that arise in “traditional testing.” TDD, rather than testing one big system, tests small chunks of code at a time. It also “follows an iterative process, where small chunks of code are developed, tested, and refined until they pass all tests.” This allows for errors to be found, debugged, and fixed as early as possible in the development process (BrowserStack).
In Kent Beck’s blogpost, “Canon TDD,” he lists the steps to properly adhering to TDD:
- Write a list of the test scenarios you want to cover
- Turn exactly one item on the list into an actual, concrete, runnable test
- Change the code to make the test (& all previous tests) pass (adding items to the list as you discover them)
- Optionally refactor to improve the implementation design
- Until the list is empty, go back to #2
Being introduced to a process that differs so much from the “norm” and is also quite efficient and thorough is both refreshing and exciting to learn about. When this topic was first introduced in class, I was very lost but I picked it up not long after; but then again, the example we followed was a very simple one. Once we moved onto a more advanced one to work on within our groups, I was lost again. I understand the concept of Test Driven Development but putting it into practice, at least for now, seems pretty hard. It also seems like a skill that is easy to pick up but hard to master as some tests can be more beneficial than others when it comes to coverage or time management.
I feel as though there are little downsides to TDD and when it comes to those downsides, they mostly lie in the capability of the individual. Forgetting to run tests, writing too many tests, writing too much for a test, and writing tests that are impractical are just some of the issues that may arise when using this practice.
Overall, Test Driven Development is a practice that individuals and teams may want to use to try something new or to test if it’s more effective than their current one. It‘s a very different approach to the development processes that I’m familiar with but that’s not always a bad thing; and in this case, TDD seems like a great practice.
Sources Used:
https://www.browserstack.com/guide/what-is-test-driven-development
https://tidyfirst.substack.com/p/canon-tdd
From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.