In his May 1st posting, Martin Fowler argues against the long-term usefulness of GUI based test automation.

"For much of my career test automation meant tests that drove an application through its user-interface. Such tools would often provide the facility to record an interaction with the application and then allow you to play back that interaction, checking that the application returned the same results. Such an approach works well initially. It's easy to record tests, and the tests can be recorded by people with no knowledge of programming. But this kind of approach quickly runs into trouble, becoming an ice-cream cone."

Furthermore, record-playback tools take a particularly hard hit:

"Record-playback tools are almost always a bad idea for any kind of automation, since they resist changeability and obstruct useful abstractions. They are only worth having as a tool to generate fragments of scripts which you can then edit as a proper programming language, in the manner of Twist or Emacs."

Read the full article on the TestPyramid and learn a little bit more about succeeding with Agile:

http://martinfowler.com/bliki/TestPyramid.html

OK, I'll bite.  We need more activity here on TSS anyway.

The first tests you should write are your end-to-end tests.  They are the only way to catch integration bugs, and your GUI needs to be tested too.

If your application is web based you can use a tool like Google Web Driver to do end-to-end tests with your supported browser(s).  These tests are no more brittle than unit tests.  If your GUI changes you'll have to change the end-to-end tests.  If the functionality of your methods change you have to change the unit tests.

The test pyramid assumes you'll have all of the schedule and budget you'll need for testing, which is wildly optimistic.  If you write end-to-end tests for your use cases you'll be in a better situation to deal with sudden cuts to schedule.  If you don't write the end-to-end tests first and you schedule gets cut you'll be left with no integration tests and no GUI tests.  If you get all of the schedule you need you can write the whole test pyramid.

Of course, if you have a system test team they will take care of the integration and GUI testing, but Fowler says nothing about this.

When deciding which tests to write first you need to be realistic about your schedule and budget.

Another critical factor in writing tests is your test database.  It's usually best if you can get a copy of the existing production database, but in new develoment that won't exist.  You need to determine how much or your test budget to spend generating good test data.

Good test data is the starting point for the test pyramid.

"These tests are no more brittle than unit tests"

They are if they are recorded - because the recorder doesn't come up with abstractions.  The structure of your page can therefore break a test that is not testing the structure of the page.

Reading through your post there is nothing there that opposes MF's view - whether to do end-to-end tests is not the question, but how to do them (specifically, should you use selenium IDE).

When I said that end-to-end tests (or GUI tests) were no more brittle than unit tests it was in the context of using something like Google Web Driver, which is probably less brittle than record-playback.

It's been a few years since I tried Selenium, but at that time it could only handle very simple AJAX.  Hopefully it's gotten better.

Where I differ with Fowler is that I believe that end-to-end tests should be done first.

"Record-playback tools are almost always a bad idea for any kind of automation, 

Did Martin Fowler say this ever before? Record-playback tools are there in the market for at least 15 years. Why did it take so long for him, as a respected figure in the software industry, to say this? 

At least one of the major problem with the software industry is the herd mentality. When EJB's were a fad, everyone, including the 'experts' were supporting them. It's a similar thing with the record-playback tools. So much time and money of the industry is wasted on these tools. 

Martin Fowler is not just a tech writer. He is involved in the software development process. He must have known that people have been spending so much money and time on these tools. Why did he take so long to talk? For a sane developer, who wants to argue to his manager that record-playback tools don't make much sense, Fowler's take on these tools would have been of tremendous help. 

Let me try this - I believe that the respected figures like Fowler can do a lot of benefit by weeding out nonsensical tools and technologies than by inventing or evangelizing new tools of technologies.

The record-playback tools have their place. But their value is very much overrated. I would be very surprised if this was not obvious to any honest thinking developer in the first one week of knowing those tools.