Re: Testing business rules and not deploying the entire stack

Hi Rakesh,

First off I think it's good to clarify what your actual business
requirements are - is the REST API *really* part of your business
requirements or is this actually an infrastructure thing? Getting the right
answer to this should start to push you in the right direction.

Can I ask what you mean by the full stack? Do you mean a bunch of web
services coordinating together + web page or are we talking more single
REST service?

There are many layers of testing you can apply to ensure you're covering
what you want, and the further up the stack you go the less of them there
are.

Regardless of your ultimate stack, it is always a good idea to step away
from your infrastructure as soon as possible, ala ports and adapters.  Have
your REST implementation have a single responsibility of handling the HTTP
part and *nothing else*.  Push in a collaborator and have that handle all
the rest of the work.  In this way you can have a suite of tests that run
against that collaborator and ignore the HTTP part.  This can be where the
core of your high level tests go - and they're just Java code so you can
apply whatever faking/mocking you *need* to and keep them fast.  I would
also have a few higher level tests that actually poke the HTTP as well -
but this is a much smaller subset that just verify the plumbing and let you
drive the initial implementation.

If you have multiple services talking to each other, have yet another level
of tests that just smoke test the plumbing between them.

Hope this helps


On Tue, Apr 2, 2013 at 3: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
>
> [Non-text portions of this message have been removed]
>
>  
>



-- 
Maybe she awoke to see the roommate's boyfriend swinging from the
chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.


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