As a software engineer, I am obsessed with doing quality work, and I have found that applying the TDD technique has helped me a lot in building quality software products.
But despite my personal experience, I have found that TDD is not really a popular practice in the industry, from what I can see from my LinkedIn network and my last few colleges at work.
Since I see here on Taro that there are a lot of really professional software engineers (I want to be like you guys!), I would love to read your opinions about it
Thanks for reading me!
From my personal experience, I've always found it more intuitive to write tests AFTER I actually build the endpoints/React components (I'm full stack). I know that TDD preaches the exact opposite but found it quite obstructive to my thought process - especially when I'm building something new and still trying to figure out how things work.
But I found TDD to be particularly useful when existing code gets refactored because it helps to catch bugs. TDD has saved me multiple times in situations like this - where I refactor one portion of the code and my changes caused something else to break.
Hope to hear what others think and I do wonder if I've been doing this wrongly too!
I like TDD in theory, but I've rarely (almost never) seen it in a Big Tech company.
A long time ago (2010), I interviewed at Pivotal Labs, an "agile software development consulting firm" in SF and they seemed to really believe in TDD. In fact, my entire interview was going through a TDD exercise for a programming puzzle where they wanted me to write a bunch of tests first.
I think a lot of this depends on the domain of software. Some areas of software with clean interfaces and no UI components are easier to do unit testing on. I can say with conviction that TDD was not a thing for mobile developers at Meta, and in fact testing was also quite sparse
On the other hand, I think backend teams had a better culture of testing.tl;dr TDD gets talked about a lot more than it gets implemented.
More great discussion here: Automated vs manual UI testing?
I find that it slows me down because as my code evolves, I have to refactor my tests to fit the code.
When I write code for a new feature, I have a general direction that I want to take it, but along the way, I will discover a better way of writing the code. The new way is usually incompatible with the tests that I initially wrote, so it can slow down development to have to refactor the code and the test.
I am not a fan of the traditional, hardcore TDD method as outlined here in Wikipedia (this is what they taught me in school 12 years ago as well):
Test-driven development (TDD) is a way of writing code that involves writing an automated unit-level test case that fails, then writing just enough code to make the test pass, then refactoring both the test code and the production code, then repeating with another new test case.
TDD is one of those philosophies that has good intent (every good engineer wants to write good code, including me), but struggles because it's trying to fit things into dogma. This is why I've rarely seen actual TDD used at a top tech company (it wasn't the case at Robinhood and it certainly wasn't at Meta).
In fact, I strongly believe that 95%+ of software applications don't need any automated tests at all until they clear 100k+ active users.
At Course Hero, we didn't have any automated tests at all on the Android app (we initially tried but ROI was very dubious), and the Android app had the highest ratings among all surfaces (Android, iOS, and web). At Instagram, we scaled the mobile apps to 1 billion+ users with <5% automated test coverage.
At the end of the day, automated tests are just 1 tool in the massive toolkit for increasing code quality. There's many others like planning things out proactively, thinking through edge cases, writing crisp PRs, dogfooding, A/B testing and phased rollouts, and analytics + alerting. The tools that make the most sense will vary based on so many factors from the type of software being built, its maturity, the team surrounding it, and far more.
To deep-dive into how to write better code (including how it's done at places like FAANG), check out our code quality course: [Course] Level Up Your Code Quality As A Software Engineer
Thank you all for share your opinions :)
I believe that having results is what matters, using whatever the team is stronger and has more experience.
Your answers helped me to understand better how it works in different places, outside of my burble 😌