You seem to be confusing unit testing with TDD. Don't take giant leaps of faith, instead take small, clear-view, steps.įinally, if you could provide me with the scenario you have in mind I could help you out with it. TDD, at its core, is about incremental change. Oh, that's not what he had in mind? Then ask him to point it out how it is not. You see, if you have any given requirement, fully-detailed or not, and you need to get implementing it, you will always have a scenario to implement, if it was not defined by the Product Owner (or similar role) you will take a guess and go for it, right? So, you create a test for that scenario. And, yes, it's true that TDD needs clear and defined requirements, but that does not mean that these requirements are final. It's hard to describe it without a clear example, but I can assure you I have created and evolved dozens of high-level features using TDD. Started with the most basic test, then moved bit by bit, by writing tests that would depict the outcome I wanted. Even though it's not based on the library I mentioned above, this one uses Flask, I took the same approach with it. And that's how we keep the system evolving, adding new features and modifying behavior, make sure everything else is in place.ĮDIT: For a more practical example, one can have a look at this test file which is from a personal project of mine. Later on, we would be adding tests that represent a bunch of business rules, like if you create a Foo object a related Bar object should exist in the database, with a given set of characteristics. Now we create the model, with some fields, and make sure the wiring on the serializer is in place. Then we add an assertion for the content, which must be an array. Completely dummy at first, since the test only expects a 200_OK status_code. Then we add the route, create the view and the serializer (it's a Django REST Framework API) and we get a response. It's an API, and the first test we wrote was to successfully do a GET to an endpoint. I'm currently working on a project which we started back in Jan 2015, greenfield, with TDD through and through. Literally everything got easier.Īnd don't even get me starting on working on an old codebase with a good suite of tests. It was like being in a super dark tunnel, and finding a flashlight. It's one thing to see TDD as a way to confidently write a brand new feature, it's a whole other ballgame to see it as a way to confidently navigate and tease apart legacy code. Once that was done, the overall change was as simple as adjusting a couple of assertions, causing those tests to fail and reimplementing the methods to meet their new expectations. So I put together a suite of tests around them (prior to making any code changes) to verify and document what they were really doing. I needed to change the behavior of a couple of methods, but I wasn't super sure what their current behavior was to begin with.Ī lot of folks would reach for their debugger and spend the next while meticulously stepping through the code. One of the biggest "aha"'s I've had was when working on a legacy codebase with very few unit tests.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |