Re: Testing business rules and not deploying the entire stack

actually, thinking this through, I can see other issues.

Lets say use case A returns object Foo for a GET and use case B returns
object Bar for a GET. A generic GET method in one super controller would
need to know which business method to call to return the right type. Thats
logic thats not easily tested.

If I go back to the use case per controller pattern, then I know in the GET
method what the return type should be, but now there no point passing in
the url that was called because it was already routed (and un-tested).

It seems I would have to compromise somewhere and hope that the area I left
untested is too simple to go wrong such as routing. Perhaps a few
integration tests with a container to test the routing would alleviate
this? Or to test the correct business layer method is called?

Rakesh


On Wed, Apr 3, 2013 at 9:58 AM, rakesh mailgroups <
[email protected]> wrote:

> Hi Matteo,
>
> an approach that like that would have consequences for how to use the REST
> framework.
>
> For example, lets take Spring MVC. The traditional approach is to create a
> controller for a specific use case and use annotations for GET and POST.
> The url routing would also be done via annotations and so passing that into
> the business layer would be irrelevant.
>
> However, if I had just one controller that received all incoming requests,
> and then methods for GET, POST, DELETE and PUT which gathered all the
> params and the url and passed to the next layer, it could work. This
> controller is clueless which use case I need.
>
> But I've never seen that approach in the wild and definitely not in any
> REST framework code.
>
> Any thoughts?
>
>
> On Tue, Apr 2, 2013 at 5:14 PM, Matteo Vaccari <[email protected]> wrote:
>
>> **
>>
>>
>> On Tue, Apr 2, 2013 at 4:53 PM, rakesh mailgroups <
>> [email protected]> wrote:
>>
>> > Hi,
>> >
>> > I'm building a new system and I want to get it 'right'.
>> >
>> > What does right mean? It means I want to test my business rules against
>> > just Java classes.
>> >
>> > This approach has been advocated by Uncle Bob (I believe) and is very
>> > seductive because I have worked on many projects where eventually, due
>> to
>> > running on a full stack, the test suite begins to slow down drastically.
>> >
>> > The approach seems to be to express your business requirements in a
>> > non-infrastructure related way. I can just about see this with a web app
>> > with a html front end. Instead of saying 'click button Add User', you
>> could
>> > say 'select Add User' and call the underlying service call that the
>> > controller was going to.
>> >
>> > (You still don't know if the button works of course, but you could have
>> a
>> > few, full stack tests to make sure).
>> >
>> > This approach has some disadvantages though. The main one being you
>> cannot
>> > always separate the business requirements and the infrastructure.
>> >
>> > A classic example is a RESTful web service. The business requirements
>> are
>> > full of GET, POST, DELETE, PUT, urls, application media types and JSON
>> > payloads. Writing requirements in this language makes sense to everybody
>> > involved including public consumers of the service and to abstract away
>> the
>> > http infrastructure seems wrong.
>> >
>> > Of course, once I start running my tests against a deployed web app, I
>> am
>> > now back to square one regarding quantity of tests and how long they
>> take
>> > to run.
>> >
>> > Any suggestions?
>> >
>> > Thanks
>> >
>> >
>> Hi Rakesh,
>>
>> the trick I would use if I were you is to create my "business" object
>> inside the servlet (or action class or whatever your preferred web
>> framework asks you to use.) I would pass to this object the method,
>> parameters, uri and whatever else it needs, and I would test that it
>> returns the proper status code, attributes and body.
>>
>> There is a longer description of how to do it in this post by Misko Hevery
>>
>>
>> http://misko.hevery.com/2009/01/04/interfacing-with-hard-to-test-third-party-code/
>>
>> Matteo
>>
>> [Non-text portions of this message have been removed]
>>
>>  
>>
>
>


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/