Hello,I'm hearing a lot of good things about the GOOS book.But...Does this book discuss or show examples(s) on how to write end-to-end acceptance tests for one or more of these flavors of applications:1. Java EE based web applications2. Swing based desktop applications3. general, MVC-based applications with GUI (ie, not console-based client/server type of applications)
I'm new to TDD (and even automated testing), so I'm not sure what tools typically get used for writing end-to-end / Acceptance Tests just as...4. JUnit gets used for Unit Tests5. jMock gets used for Mock TestsWould the forum members kindly share the tools they are using for Acceptance Tests?
In essence, I don't get ALL of the following all together:6. In TDD, you are supposed to write tests first, before ANY code gets written!
7. The GOOS book is (apparently) recommending to write Acceptance Tests (over excessive class-level Unit Tests).
8. But the GUI is not ready YET... not before the first line of code has been written. A chicken-and-egg problem?
9. For a GUI, MVC-based app, is it enough to have the Acceptance Tests driven by the Controller? Or, must they be driven by the View?
Would greatly appreciate your kind responses and insights. I'm in a great hurry to adopt TDD but am feeling truly overwhelmed by the literature around it. Some books on TDD appear to be almost a decade old, so I'm not sure if the techniques covered in them would still be the state-of-art in 2015. In other words, I won't be able to tell from these books themselves (even if I could purchase all of them AND read all of them cover to cover) if their content is still valid and has not been superseded by something better.
Many thanks in advance.Regards,/NS
--
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi NS,
Some of the answers to your questions are covered in the GOOS book. If you are looking for an alternative (or a prequel) to GOOS, I suggest TDD By Example by Kent Beck. It's still very relevant. Also the videos by Kent Beck published with Pragmatic Press.
Anyway, the way to learn from a TDD book is to follow along the examples with your IDE.
My suggestion to get started is to concentrate first on doing TDD well and pospone learning about end to end AT.
Matteo
On Aug 29, 2015, at 11:19 AM, NS <pingn...@gmail.com> wrote:8. But the GUI is not ready YET... not before the first line of code has been written. A chicken-and-egg problem?I didn't understand this. Did you mean that you are working on an application and the GUI is being designed separately?
9. For a GUI, MVC-based app, is it enough to have the Acceptance Tests driven by the Controller? Or, must they be driven by the View?It depends. If you can design your application on a way that avoids a lot of logic in the view, you can get a lot of confidence in your acceptance tests by avoiding the view. These tests tend to be faster and more reliable than tests that use the view.
Typically I find a need a balance of a few view-driven tests to make sure everything is hooked together correctly. Then I prefer more fast unit tests, with a few slower tests that check the parts that integrate with the external inputs and outputs - eg the database, talking to web services, etc.
My understanding of an end-to-end acceptance test is, a test that:
- emulates an enduser (who will 'accept' the delivered system, finally)...
- exercising all the major layers of the system...
- deployed in (almost) a realworld- / Production-like environment.
Which means, you must use tools like Selenium, LoadRunner, or Grinder (although the latter two are used primarily for performance testing) that allow you to record all the GUI actions of yours in order to (easily) build your acceptance test.
In absence of such tools, you'd have to manually (and very tediously) build the equivalent GUI driving 'script' yourself somehow.
So, what I was trying to say in my original post was,IF,a) given that an end-to-end acceptance test is not *supposed* to be drivenby the non-visual, non-iteractive Controller code behind a GUI View butdriven rather by the GUI View itself;*AND*b) given that TDD requires the (acceptance) tests to be written firstTHEN,doesn't it become a chicken-and-egg problem (unless of course youchoose to tediously build the View driving script manually)?
Well, what if the View is highly rich / interactive / GUI-event-driven, containing not business logic but rather enough View-state and View-logic to warrant its (automated regression) testing, *AND* such a View happens to be part of the acceptance test demanded by the end-user? For example,
- The enduser may demand that "if I click widget 1, then widgets 2, 3, and 4 must be disabled, etc.
- Some dropdowns may list different choices based on enduser's interaction with other widgets in the same View.
- Etc.
Typically I find a need a balance of a few view-driven tests to make sure everything is hooked together correctly. Then I prefer more fast unit tests, with a few slower tests that check the parts that integrate with the external inputs and outputs - eg the database, talking to web services, etc.While speed matters and is obviously welcome, I'm not so much worried about speed, especially in the context of end-to-end acceptance testing when one of its big (potential) gifts (as I understand so far) could be an automated regression testing of the whole system -- from the GUI down to the database. Thus, I would very much want to include my highly interactive GUI in my acceptance test coverage, if possible.
Maybe, I'm missing the definition of an acceptance test in context of TDD.
On Sat, Aug 29, 2015 at 10:36 PM, NS <pingn...@gmail.com> wrote:Maybe, I'm missing the definition of an acceptance test in context of TDD.From what you describe, my interpretation is that your primary point of confusion was thinking that the GUI tests must be written using a record-and-playback tool. Did I get that right? Otherwise, it sounds like you are on the right path!
IF,a) given that an end-to-end acceptance test is not *supposed* to be drivenby the non-visual, non-iteractive Controller code behind a GUI View butdriven rather by the GUI View itself;*AND*b) given that TDD requires the (acceptance) tests to be written firstTHEN,doesn't it become a chicken-and-egg problem (unless of course youchoose to tediously build the View driving script manually)?
Some say that one of the major thing achieved through testing first is that from the tests should emerge design.
If you can, try to avoid any hypothesis about pattern you could use. Let them in some dark place in your brain, and use them when your process will lead you to them.
Actually, it is like waiting for the question to provide the answer.
I hope I do not speak rubbish like some green Jedi I know of... Whenever I have to teach TDD to colleagues, it always cumbersome to tell them how to do it... It often ends with trust, that I should lead them to some nice place at the end... :)
Have a nice day...
If you test through the GUI and write tests first AND REFACTOR RELENTLESSLY then refactoring away duplication will drive abstractions out of your test code that model the user's interactions with the system. Your next tests written against those abstractions will not be so tedious to write. And as you continue to write tests and refactor, those abstractions will improve, becoming more expressive, and more closely modelling the tasks of the users and the business domain the users are working in.Pretty soon it should be MUCH faster to write tests first than to use a record/replay GUI testing tool. In projects where I've run a lot of acceptance tests through the GUI, writing new tests eventually involved a few minutes sitting at the IDE with a domain expert (business analyst, client, or whoever).That sounds like *arriving* at Model-View-Presenter (MVP), but *via* refactoring. If yes, then owing to its TDD-friendliness out-of-the-box among other benefits (like Presenter reuse, loose View-Model coupling), I might as well *start out with* MVP, especially its "dumb-View" flavor. I could, then, call my entire Presenter layer as pretty much the GUI, and in turn, call my Presenter-driven end-to-end test an acceptance test.
--
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On 1 September 2015 at 05:26, NS <pingn...@gmail.com> wrote:If you test through the GUI and write tests first AND REFACTOR RELENTLESSLY then refactoring away duplication will drive abstractions out of your test code that model the user's interactions with the system. Your next tests written against those abstractions will not be so tedious to write. And as you continue to write tests and refactor, those abstractions will improve, becoming more expressive, and more closely modelling the tasks of the users and the business domain the users are working in.Pretty soon it should be MUCH faster to write tests first than to use a record/replay GUI testing tool. In projects where I've run a lot of acceptance tests through the GUI, writing new tests eventually involved a few minutes sitting at the IDE with a domain expert (business analyst, client, or whoever).That sounds like *arriving* at Model-View-Presenter (MVP), but *via* refactoring. If yes, then owing to its TDD-friendliness out-of-the-box among other benefits (like Presenter reuse, loose View-Model coupling), I might as well *start out with* MVP, especially its "dumb-View" flavor. I could, then, call my entire Presenter layer as pretty much the GUI, and in turn, call my Presenter-driven end-to-end test an acceptance test.I was talking about the structure of the *test code*, not the application itself. To test through the GUI the tests need to:* query what's showing in the UI* send events to the UI* synchronise with asynchronous behaviour of the UI (and rest of the system)* model the structure of the UI screens/dialogs/pages so that each is defined only in one place in your code* model the navigation routes around the UIAll that would be, as you say, quite tedious to write if you had to write it anew for every test. But if you continually refactor your test code, then abstractions will emerge from the refactoring that make it easier and easier to write tests.At the same time, continually refactoring the system as it grows will (in my experience and as we described in GOOS) drive the design of the system towards a Ports-and-Adapters* architecture, so that you can test more and more significant behaviour of the system without testing through the UI at all.
--
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On 1 Sep 2015, at 11:55, Steve Freeman <st...@m3p.co.uk> wrote:For videos, I quite like JB Rainsberger’s new series.
Nat,
Could you please provide links to the talks you recommended?
Nat,
Could you please provide links to the talks you recommended?
Thanks a lot, Nat!
On 8 September 2015 at 14:26, Suhas Walanjoo <suhas.w...@gmail.com> wrote:Nat,
Could you please provide links to the talks you recommended?
There are a bunch of videos online. Not sure which is best.
On Sep 1, 2015 5:46 PM, "Nat Pryce" <nat....@gmail.com> wrote:
Also JB's talk, Integrated Tests are a Scam, is v good overview on how to avoid end-to-end tests altogether.
I would suggest not getting too hung up about completeness if you’re completely new to the technique.
Start with the bits you can understand and work from there - but /keep pushing/. Unless you’ve gone too far, you can’t know where the boundaries really are.
For videos, I quite like JB Rainsberger’s new series.
S
--
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
http://www.natpryce.com
--
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.
If integrated tests are a scam, why do we start outside in TDD with an end-to-end test?
>>It is then possible to write acceptance tests against the domain model>>in memory rather than end-to-end. From then on, starting with an>>acceptance test does not mean starting with an end-to-end test.You do this very much or are you just saying that it is possible?
Thanks Nat.
--
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.