At the last Virtual Brown Bag we talked about Test-Driven Development (TDD), Behavior-Driven Development (BDD), and related subjects (you can watch it here).
I’ve been very fortunate in the last 5 years working on projects where I simply write the tests as part of the work. It’s just something I do.
Is it a new feature?
If I need to work on a new feature, I write the tests to spec out my understanding of the feature. If I can’t write the test, most likely I don’t understand what the feature is, and if that’s the case, I shouldn’t write any code to begin with. Instead, I should pair up with the QA guys and/or the business analysts (or work directly with my client), and make sure I understand not only what the feature is, but also why it is important to the business.
Is it a defect?
If I need to work on fixing a defect, I’ll do my best to write a test that reproduces the issue. Granted, some issues (such as multi-threading issues) are really difficult to reproduce in test, but hopefully those types of issues aren’t the core of my projects. Whenever there is an area that’s hard to test, I’ll try to isolate as much of the code as possible, decreasing the surface that’s hard to be tested.
The biggest lessons I’ve learned from testing
While I think I’ve learned quite a bit about the technical aspects of writing tests, and have been harvesting so many positive outcomes, such as writing better code, I don’t think that alone makes me a better developer.
I believe that the act of taking a step back to think about how I’m going to write tests has made me take an extra step back to understand what it is that I’m building. This has made me collaborate a lot more with people who actually understand the business. I don’t really care much anymore about using this or that framework/language/etc just because it’s cool; I care much more about building features that will bring value to my client. Seeing a client smile because you gave him or her the feature needed is very rewarding.
A recent experience
In the last 3 months I’ve been working part time on a project where I’m the only developer, and I have no QA, no business analyst, no project manager. Here are some bullets from my personal project notes:
- The first phase of this project has gone into production two weeks ago
- The client is beyond happy
- Very few defects were found in production (and corrected immediately)
- There are close to 400 tests
- I do NOT have everything under test. I’m keeping Controllers very thin, calling out to Commands, Services, etc. Things the controllers call ARE under test.
The whole testing thing…
As I finished writing this post, I just remember I actually wrote another post about the whole testing thing 8 years ago! Time sure flies by…
Claudio Lassala's Blog 