Re: Re: Testing business rules and not deploying the entire stack

I'm so sorry I got your name wrong.  Don't know what I was thinking


On Thu, Apr 4, 2013 at 9:22 AM, Matteo Vaccari <[email protected]> wrote:

> Hi Debasish,
>
> my strategy is to let the fw call me, and avoid dependencies on the
> framework in my code. It was fairly successful in a project one year ago.
>  Our entry point was a single servlet, that called our own routing object,
> that selected the appropriate controller factory, that created the
> controller and so on.  It is very fast, memory efficient and easy to test.
>
> BTW in our project we also used end-to-end tests.
>
> Matteo
>
>
>
>
> On Wed, Apr 3, 2013 at 6:43 PM, <[email protected]> wrote:
>
>> hmm, I responded this morning but my reply hasn't shown up yet! Copying
>> my reponse:
>>
>> 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?
>>
>> Then i added:
>>
>> 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?
>>
>> --- In [email protected], Matteo Vaccari <vaccari@...>
>> wrote:
>> >
>> > On Tue, Apr 2, 2013 at 4:53 PM, rakesh mailgroups <
>> > rakesh.mailgroups@...> 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]
>> >
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>


[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/