OK I've developed a few new features using TDD; I've wrapped some legacy functionality with acceptance tests while bug fixing. But I still don't "get it". I'm trying to tackle a few new features, before I switch into refactoring mode on the legacy code. But I can't seem to figure out how to get to the first test.
These three features are all of the form "Gather Some Data from the User (Validate/Re-Gather if needed); Generate a Report". I could probably tackle the "Generate a Report" portion via mocking, so maybe that's what I should do.
I think to some degree my "problem" is that I still don't understand how TDD and UI interact. I'm used to
- Developing the forrm
- Building up the cleansing/validation/force re-submit
- Processsing the Form
- Generating after action report/options/status
normally in that order. TDD seems to ignore the first step, which kinda leaves me dangling over a chasm not knowing where to start.
I can kinda see the Handler example McGruff illustrated in my Funny Experience thread partially addressing the second step (coupled with the input controller), but seeing how I don't have the infrastructure for the Handlers nor an Input Controller yet I can't quite get there.
Perhaps I need to take a step back from working on addding features to the legacy application and start growing a more complete OOP framework first? Is there some other perspective that might help me find a starting test?
Thanks
Change of Perspective needed?
Moderator: General Moderators
Re: Change of Perspective needed?
Although you can jump in at a mid-point with TDD you're committing (unwritten) objects to the north to use a particular interface. That might work out OK but it's safer to start at the top. In the beginning, something is waiting for an http request...nielsene wrote:Perhaps I need to take a step back from working on addding features to the legacy application and start growing a more complete OOP framework first? Is there some other perspective that might help me find a starting test?
Alternatively you can use state-based tests and work from the domain up, as mentioned by Fowler (not something I've tried).
Writing good framework code is possibly one of the hardest things to do. It has to be capable enough to work well with different cases but it shouldn't become bloated. Perhaps the skill is in making the right compromises so that it's useful for most things. Or maybe you could concentrate on a particular domain.
XP do-just-what-you-need maybe suggests that you should focus on more specific goals and let a framework emerge - refactored later out of the code you have written. On the other hand if you're sure you can define requirements for your framework, you could try starting with that.
The ChainOfResponsibility/RequestGateway idea is as far as I've got with controller frameworks. It's simple enough for simple cases or, by throwing in more handlers, it can cope with complex application controller logic. You see variations on this theme quite often for example in InterceptingFilter. I think WACT has some kind of nested ChainOfResponsibility but don't quote me.
WACT itself might be an option - and it's fully-tested
Yeah, I've decided to try working from top down now. I have the start of my first few Contexts,Requests,and Handlers working now. Its still slower progress than I'd like. I'm going to have to hit the Front Controller/Module Controller (as I discussed in the T&D forum) very soon and that scares the heck out of me. Mainly because I need to FC that can fall back to the all the existing pure scripts while letting me slowly migrate to the new frame work.
I also need to tackle the whole view component soon as I've have a few Handlers that are ready to generate a response. This also confuses me. I prefer TemplateView to TransformView and I've always felt that PHP is a fine templating language, but I don't see how to integrate that with a "classful mode". I could just "include $viewName" but that smells to me. However any bundling into a class will require eval() which is equally stinky.
I also need to tackle the whole view component soon as I've have a few Handlers that are ready to generate a response. This also confuses me. I prefer TemplateView to TransformView and I've always felt that PHP is a fine templating language, but I don't see how to integrate that with a "classful mode". I could just "include $viewName" but that smells to me. However any bundling into a class will require eval() which is equally stinky.
Including a template in the same scope as the template vars and using php as the template language is maybe the simplest thing that works. The vars might be in a container, or just lying around in the class/method scope. What is it about this that makes you uncomfortable?nielsene wrote: I prefer TemplateView to TransformView and I've always felt that PHP is a fine templating language, but I don't see how to integrate that with a "classful mode". I could just "include $viewName" but that smells to me. However any bundling into a class will require eval() which is equally stinky.