Software developer trying to bring order into his craft. I write about my journey, thoughts, and practices. Currently focused on web frontend with React.
I agree that in real-world applications, it's harder to do TDD. In my opinion, it's due to the increase in the complexity of the domain. So my strategy has been to break features down into degenerate cases that are simple enough for me to know how to write a test for them. After implementing the degenerative case, I then proceed to iterate into the next degenerate case that brings me closer to the full-fledged feature.
This example is a bit too simple, but if I have to develop a table that fetches data and has tons of sort options, my tests will probably go something like this "Shows loading while fetching" -> "Can show an error message when fetching data fails" -> "Show's message to the user if there's no data to show" -> "Can show one row" -> "Can show multiple rows" -> "Can filter rows by 'Property1' " -> "Can filter rows by 'Property2' " -> "Can filter rows by 'Property1' and 'Property2' " -> etc. Some tests might be redundant at the end of the implementation, and I'll probably delete them if that's the case. But going through this process gives me more confidence in what I'm doing and tend to lead to better tests and design.
Small steps help a lot.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree that in real-world applications, it's harder to do TDD. In my opinion, it's due to the increase in the complexity of the domain. So my strategy has been to break features down into degenerate cases that are simple enough for me to know how to write a test for them. After implementing the degenerative case, I then proceed to iterate into the next degenerate case that brings me closer to the full-fledged feature.
This example is a bit too simple, but if I have to develop a table that fetches data and has tons of sort options, my tests will probably go something like this "Shows loading while fetching" -> "Can show an error message when fetching data fails" -> "Show's message to the user if there's no data to show" -> "Can show one row" -> "Can show multiple rows" -> "Can filter rows by 'Property1' " -> "Can filter rows by 'Property2' " -> "Can filter rows by 'Property1' and 'Property2' " -> etc. Some tests might be redundant at the end of the implementation, and I'll probably delete them if that's the case. But going through this process gives me more confidence in what I'm doing and tend to lead to better tests and design.
Small steps help a lot.