Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Im not a TDD expert or anything but when I'm developing a web service I write a couple of tests containing success and error calls with the expected responses.
Then i start developing, once I think I finished handling a certain call, I run the tests to verify I didnt break any another cases on the service and to verify if the current change was succesful.
When not, I open my debug tools and fix the bug.
When the test passes, I wire up the frontend and then test all cases on the service from within the client -
@host127001 what about classes, interfaces, packages, all the top-down design stuff?
I guess how do you structure and plan the app? -
@billgates the toplevel stuff is mostly given by the architecture and some principles like SOLID.
I mean if you have a webservice and use a simple 3 layer architecture, you know that there will be a class each for that services web-, logic- and dataaccess-tier.
And everything else (like utils etc.) come together rather naturally, when each class/interface/function has exactly one responsobility
How do you switch from testing while debugging (functional) to TDD unit tests?
Usually I test while coding by just running the use case and making sure while coding, bad inputs are caught/handled.
But most times I start with a general idea of the structure and what the about should be (which essentially would be the functional test case?)
I don't think about how you can break each part or the functions I need until I need them. Then usually start simple and then refactor. And until I'm sure each time I refactor would require changing the tests?
question