The Page Objects design pattern is outlined in the Selenium wiki, but to summarize, Page Objects are meant to encapsulate the messy internal state of a page. Changes in the presentation code should only require changes only to the Page Objects, not to the actual test code. Using a Page Object promotes consistency; there may be five different ways to legitimately determine that you are on the login page, but adhering to the one definition in the Page Object will prevent you from having to maintain the other variants.

Page Objects should be ignorant of an application’s business logic, they should only be aware of page state and how to interact with it. By clearly delineating the test code from the page objects, you will be able to use the same page objects in a variety of tests cases and achieve code re-use.

Continue Reading 3 comments

One of the “softer” sides of development is time management. We do this on both a macro scale (project planning, estimates, what goes into the Sprint, etc.) and a micro scale (what am I going to work on today?). Most developers on most days are concerned with micro time management — and many good project managers realize a lot of important decisions get made there as well (“it seemed like it would be a quick to fix so I went in and did it” or “Gina came over and asked me about this defect so I fixed it.”). This is especially true of programmers on many projects, a few teams, and with some maintenance and support involved in their work.

I do not profess to have a solution — I thought I would share three strategies that I have tried over my career (I am sure there have been others). If you want to try one of these, great! Let me know how it goes! If you have another approach, please share or email!

Continue Reading 8 comments