It's not very clear from this post whether the author ever includes the UI in the integration tests or not.
Personally I think that's where the Presentation Model pattern really shines: it allows you to strip the thin view layer from your fully integrated application and do automated integration tests by invoking the presentation model(s).
In the Growing Object-Oriented Software book, which Misko recommended, the proposed technique is to start with a higher-level test (integration/acceptance/functional) and only then go to the lower level of unit tests and classes. This way, you are sure not to write unit tests and classes that YAGN, because the current failing acceptance test gives you the big picture.
@Giorgio That sounds like good advice for an existing application that has little to now test coverage, especially one that is in maintenance mode as there is likely going to be large chunks that will never change. However, the application discussed sounds as if it was new, and it was written w/TDD to begin with so the risk of ending up with unit tests that YAGN is low as there's already a lot of coverage.
I'm with @Wim on this one as testing through the UI is frought with peril: http://blog.objectmentor.com/articles/2009/09/29/ruining-your-test-automation-strategy http://blog.objectmentor.com/articles/2010/01/04/ui-test-automation-tools-are-snake-oil
@Mark Roddy: The approach in the GOOS book is not presented for "an existing application that has little to no test coverage", but for greenfield projects. The end-to-end tests are the first lines written in the project.
The goal is to solve all the integration problems (which are usually high-risk) at the beginning of the project. I also perceive that it helps in driving the design of the lower level code so, that all pieces will integrate well together.
If you start by writing the lower level components, then when you get to the point of integrating them, it's possible that their design makes it hard to integrate them and the design must be changed, because the code was not designed for integrability since day one. The same way as using TDD makes the code designed for testability, because the tests are written first, starting with end-to-end tests makes the code designed for integrability, because the code is integrated first.
@Wim Coenen: The project I wrote about contains very little GUI, which is tested through the model, not the UI. However, the tests do cover command line invocations by the user and emails sent to the user. Depending on your point of view you might consider those part of the UI.
It's not very clear from this post whether the author ever includes the UI in the integration tests or not.
ReplyDeletePersonally I think that's where the Presentation Model pattern really shines: it allows you to strip the thin view layer from your fully integrated application and do automated integration tests by invoking the presentation model(s).
In the Growing Object-Oriented Software book, which Misko recommended, the proposed technique is to start with a higher-level test (integration/acceptance/functional) and only then go to the lower level of unit tests and classes. This way, you are sure not to write unit tests and classes that YAGN, because the current failing acceptance test gives you the big picture.
ReplyDelete@Giorgio That sounds like good advice for an existing application that has little to now test coverage, especially one that is in maintenance mode as there is likely going to be large chunks that will never change. However, the application discussed sounds as if it was new, and it was written w/TDD to begin with so the risk of ending up with unit tests that YAGN is low as there's already a lot of coverage.
ReplyDeleteI'm with @Wim on this one as testing through the UI is frought with peril:
http://blog.objectmentor.com/articles/2009/09/29/ruining-your-test-automation-strategy
http://blog.objectmentor.com/articles/2010/01/04/ui-test-automation-tools-are-snake-oil
-Mark
@Mark Roddy: The approach in the GOOS book is not presented for "an existing application that has little to no test coverage", but for greenfield projects. The end-to-end tests are the first lines written in the project.
ReplyDeleteThe goal is to solve all the integration problems (which are usually high-risk) at the beginning of the project. I also perceive that it helps in driving the design of the lower level code so, that all pieces will integrate well together.
If you start by writing the lower level components, then when you get to the point of integrating them, it's possible that their design makes it hard to integrate them and the design must be changed, because the code was not designed for integrability since day one. The same way as using TDD makes the code designed for testability, because the tests are written first, starting with end-to-end tests makes the code designed for integrability, because the code is integrated first.
I think that we could avoid all this complication using ATDD (Acceptance TDD) + TDD.
ReplyDeleteI good resource is the already mentioned book: Growing Object Oriented Software Guided by Tests.
There is also other book Test Driven: TDD and Acceptance TDD for Java Developers by Lasse Koskela
Others Resources:
Using Customer Tests to Drive Development
http://www.methodsandtools.com/archive/archive.php?id=23
Slidshare (ATDD)
http://www.slideshare.net/nashjain/acceptance-test-driven-development-350264
TDD with Acceptance Tests and Unit Tests
http://blog.objectmentor.com/articles/2007/10/17/tdd-with-acceptance-tests-and-unit-tests
Thanks for the comments and pointers.
ReplyDelete@Wim Coenen: The project I wrote about contains very little GUI, which is tested through the model, not the UI. However, the tests do cover command line invocations by the user and emails sent to the user. Depending on your point of view you might consider those part of the UI.