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
