http://watchitlater.com/blog/2010/03/testing-anti-patterns-for-developers/ A reluctant foray into the world of blogging. Tue, 13 Dec 2011 12:46:52 +0000 hourly 1 http://wordpress.org/?v=3.3.1 http://watchitlater.com/blog/2010/03/testing-anti-patterns-for-developers/comment-page-1/#comment-6905 Tom Sun, 07 Mar 2010 03:00:03 +0000 http://watchitlater.com/blog/?p=180#comment-6905 @Matt, I look at this like a shell game, or one of those neat little russian dolls (where one sits inside another). For this reply I'd like to assume a "relatively" standard web app architecture with a bounded context around a domain, with repositories at one boundary and controllers/endpoints/presenters at the other (acting as anti-corruption & translation layers). I would test repository logic, type conversion, ORM, aggregation, query builders, etc at one end in their own tests without the front-end. It saddens me when I see repository tests that need the entire application to be up and running - on one project even the JMS queue had to be enabled to wire-up a single JDBC repository. I would test the controller/endpoint/presenter marshalling/unmarshalling logic at the other end, with more of the application configured but still in their own unit tests. If you are not tied to JSPs in java, you can actually test any "logic" in your templates by trying to render them out with some canned data. In a spring-wired app (for example) its not that hard to do to initialise a spring framework dispatcher servlet directly and use it in your own tests via the spring framework mock requests & responses (check out my <a href="http://github.com/tomcz/example-webapp" rel="nofollow">example-webapp</a> project on GitHub). In Rails you can actually test views & controllers separately as well (take a look at the excellent Pragmatic Programmers book on RSpec). That leaves testing page flows, AJAX-y goodness and goal based testing at the front end via a browser, HtmlUnit/HttpUnit, WebDriver, Selenium, etc. If you write your flows using simple post-redirect-get behaviour and then enhance them with JS later, you can even test the flows without a deployment or a browser. The big thing is that you don't need to test fine-grained conditions at the front-end, you just have to pick where in the various layers of your system these conditions make sense to be tested. Is it a repository test, a service test, a controller test, a rendering test, a ScrewUnit JS test, or is it truly something that needs a "full stack"? How much testing do we do at the front-end because its convenient to do so, rather than refactoring our applications to make it easier to test at various layers, and how much of our testing is really a belt & braces approach to a lack of trust/knowledge? @Matt, I look at this like a shell game, or one of those neat little russian dolls (where one sits inside another). For this reply I’d like to assume a “relatively” standard web app architecture with a bounded context around a domain, with repositories at one boundary and controllers/endpoints/presenters at the other (acting as anti-corruption & translation layers).
I would test repository logic, type conversion, ORM, aggregation, query builders, etc at one end in their own tests without the front-end. It saddens me when I see repository tests that need the entire application to be up and running – on one project even the JMS queue had to be enabled to wire-up a single JDBC repository.
I would test the controller/endpoint/presenter marshalling/unmarshalling logic at the other end, with more of the application configured but still in their own unit tests. If you are not tied to JSPs in java, you can actually test any “logic” in your templates by trying to render them out with some canned data. In a spring-wired app (for example) its not that hard to do to initialise a spring framework dispatcher servlet directly and use it in your own tests via the spring framework mock requests & responses (check out my example-webapp project on GitHub). In Rails you can actually test views & controllers separately as well (take a look at the excellent Pragmatic Programmers book on RSpec).
That leaves testing page flows, AJAX-y goodness and goal based testing at the front end via a browser, HtmlUnit/HttpUnit, WebDriver, Selenium, etc. If you write your flows using simple post-redirect-get behaviour and then enhance them with JS later, you can even test the flows without a deployment or a browser. The big thing is that you don’t need to test fine-grained conditions at the front-end, you just have to pick where in the various layers of your system these conditions make sense to be tested. Is it a repository test, a service test, a controller test, a rendering test, a ScrewUnit JS test, or is it truly something that needs a “full stack”?
How much testing do we do at the front-end because its convenient to do so, rather than refactoring our applications to make it easier to test at various layers, and how much of our testing is really a belt & braces approach to a lack of trust/knowledge?

]]> http://watchitlater.com/blog/2010/03/testing-anti-patterns-for-developers/comment-page-1/#comment-6892 Graham Sat, 06 Mar 2010 16:11:55 +0000 http://watchitlater.com/blog/?p=180#comment-6892 I can tell you have not lost your touch. Nice post! I can tell you have not lost your touch. Nice post!

]]> http://watchitlater.com/blog/2010/03/testing-anti-patterns-for-developers/comment-page-1/#comment-6891 Matt McClure Sat, 06 Mar 2010 15:07:45 +0000 http://watchitlater.com/blog/?p=180#comment-6891 Regarding #1, what *do* you suggest testing at the front end? Recognizing that you need to test *something* is step 1; testing too much and fragile tests usually result. Step 2: finding an appropriate way to test integration via the front end is significantly harder. Regarding #1, what *do* you suggest testing at the front end? Recognizing that you need to test *something* is step 1; testing too much and fragile tests usually result. Step 2: finding an appropriate way to test integration via the front end is significantly harder.

]]>