Re: Testing business rules and not deploying the entire stack

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/