tag:blogger.com,1999:blog-13243193.post7176264405015606890..comments2011-11-06T16:47:33.091-08:00David Dossothttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-13243193.post-59196972490955860672011-11-06T16:47:33.091-08:002011-11-06T16:47:33.091-08:00Thanks Juergen, you made a great case for coding front-end against &quot;the real deal&quot;.David Dossothttp://www.blogger.com/profile/13987512594987806769noreply@blogger.comtag:blogger.com,1999:blog-13243193.post-19424087128666616742011-11-06T11:53:55.009-08:002011-11-06T11:53:55.009-08:00Fully agree on all points.<br /><br />About your concern that it&#39;s not clear what the front end developer should test against: I believe it has to be an HTTP server, not a stub. Setting up a local server usually isn&#39;t difficult and if something prevents it then this should be solved until it is difficult.<br /><br />The reason here is that interaction via an actual HTTP server can be different and surprising. Proper handling of HTTP headers and status codes needs to be done even on the client side, so I would suggest to test against the real thing.<br /><br />And ideally - while surely not always possible - not just a local server, but a server that resembles a production setup (with all caches and other layers fully setup). That&#39;s again because some headers are re-written or disappear, status codes may change because of funny intermediate layers, etc. If a full production setup is done well, this shouldn&#39;t be too much of an issue, but you never know.Juergen Brendelhttp://brendel.com/consultingnoreply@blogger.com