Portland ME - Testing is very difficult. Its a pain in the butt but it's one of those neccessary evils. The more websites we build and the increasing number of web application we work on has pushed up to grow in our testing techniques. In the past testing was a final phase of a project where staff members would all hammer on the application with less than well written user stories. To be honest, the fatique of the project along with the fact that the user stories were written only weeks early proved to be an unreliable way to test applications. When the projects were small and the application not as robust, we got away with this process. However as the complexity grew we needed to advance our methodology about testing.
So lets put our adult pants on and step up our game as proffecient developers. As my dad always said, "Perfect practice makes perfect". We need to be thinking testing while we are developing, not after. If we can not get the client to sit down for 4 hours and discover all the user story lines that will be needed for UAT than us developers need to create them as we build. Obviously we are building functionality, we can at least create the stories as we create the functionality. And lets blow our project managers mind and build our Unit Tests at the same time. Typing our user stories is not fun, but creating tests with PHPUnit and Selenium Web Drive is!
Along with complexity, we still faced that pesky issue of project fatigue and unreliable story lines. It makes more sense for the developers to create the test while the building process is going on. But the test need to be project manager friendly. This is where Selenium Web Drive comes in handy. As coders, developers can write PHPUnit test but still take advantage of all the user interaction tools of Selenium as well as the visual playback of the test. And because we are writing the test at the code level, we have the power of PHP to handle complex interactions. With developers writing the tests it keeps developers focused on the story lines and provides a mechanism for developers to express to project managers how the user will interact with the functionality. Inheritantly it allows project managers and clients to push back on that interaction, but again, with a visual test developers and project managers are speaking the same language. This brings me back to Sauce Labs. If developers are using their local machine to write and run the test, how are the project managers going to see them? Well, hundling around the lap is an options, or we can make sure the tests are checked into the repo and project managers know how run the tests from the command line. Well, I know plenty of project managers that hate the command line, so that might not work for everyone. Sauce Labs provides the solutions with an awesome user interface to view test and get reports on pass and failures. Developers can write their tests locally and run them on Sauce Labs from their command line. The test is actual run on Sauce Labs infrastructure and even video recorded. Project managers can view the test that run on the Sauce Labs website and even playback the test. A beatiful centralize place for developers and project manager to live in harmony knowing they are delivering a functionality product to their client.
At the end of projects, it common to forget why functionality was created and what the requirements were. We would all like to believe our project discovery and architecture documentation can deliver us from the evil of scope creep but lets face it, projects are wild fungus' that strive to strangle us. Writing test while building functionality is just another tool we can look back on at the end of the project and keep those requirements in focus while we are creating.
I would highly suggest watching http://code.tutsplus.com/tutorials/how-to-use-selenium-2-with-phpunit--n... by Jeffrey Way to get going. Nike Air Max