the difference between an agile developer and those of a more traditional mindset is that the latter typically questions many solution aspects/requirements up front that they think may affect the design later on, in other words, they know it is going to mean pulling out the code and potentially re-engineering when change is required. this does have its place and some systems need a lot more pre-thought and detailed specification. but for most business sites these days the coding frameworks are so component based and cover the majority of areas of functionality and non functional requirements that so much pre-prep is not necessary. there is a place for business logic, front end code, database tables and data access. security models and anonymous and authentication areas of a site. as for testing - yes, quality unit and integration testing will be integral to each iteration, continuous integration should ensure that previously developed components do not break when new code is introduced. the traditional regression testing is not feasible in a 2 week iteration, agile developers are more responsible for delivering error free quality code.
every iteration has to be DONE before it is put in front of the client for review. what is DONE? done is initially agreed up front and can change throughout the course of the project. why? because agile projects adapt to the business as the project matures. DONE initially may just be a few screens with barebones functionality to demonstrate an application flow, there is no need to worry about security, tab orders, images and calculations being 100% - its just enough to demonstrate a concept to evolve. however, DONE will have some generic IT shop housekeeping activities, checked in code, versioned and baselined, documents up to date, environments aligned etc.