I want to write test cases when application is under developing. I know the design of the application based on the wireframes.

I intend to write test cases in C# using the Selenuim WebDriver.

Looking at the sheer number of the test cases, I don't think I can wait till the application is developed, but need to start writing my test cases much earlier in the application life cycle.

Are there any resources on the web (I have already googled but did not find anything relevant that answers my question) that describe when in the application life cycle should one ideally start creating Test Cases in Selenium.

  • Is the app being delivered in one big chunk or iteratively? Are the devs doing daily, weekly, fortnightly releases? Or do you have to wait 6 months? Commented Mar 19, 2014 at 11:50

4 Answers 4


I've found in the past that using a BDD framework like SpecFlow helped me with this.

You can start off writing the tests, and slowly start writing the code for it each of the tests as your able to. SpecFlow is great for code re-use, although, it can take some getting used to. An example of this is every time you use "And log in to the application", the code that you wrote to log in will be executed

A side benefit to this is being able to write your tests in a format that everyone will understand the purpose of. This can be very important.

To the final part of when to start writing the test cases in Selenium, ideally, as soon as you start writing manual tests.


Why don't you start describing your test cases in text form, or writing the stubs for Selenium tests with empty methods and test steps as comments.

It would be easier to pick up there with the code as development will evolve.


Plan plan plan!!! The greatest cost of automated tests is maintenance, and as the project grows it gets more and more difficult to do if the proper amount of planning wasn't utilized during the initial design of the test project. Whether an application is still under development or not, the first thing you should do (if you don't have one already) is write a testing framework that will interpret to webdriver calls. If you have driver doing anything in your actual test method, it's bad design and should be fixed immediately. For all of my projects, I actually have two frameworks; a very abstract base framework that can be reused across all projects, and then each project has a more specific framework that will only be used for that project. I've seen some designs that have 4-7 layers but I've never found a need to contain all navigation in a specific layer and ideas like that. My test classes initialize the driver in the constructor and that's it. The only thing webdriver is doing in the less abstract class is finding the mapped elements and navigating. Everything else is accomplished in the base framework, so you can get a lot of the work out of the way before the first page is even deployed.

The nice thing about having a base framework is it keeps your tests from getting messy and hard to read, because if you're just using Webdriver, you've got two options: Dynamically find each element with the driver or create an element that is specific to one browser, i.e. FirefoxElement or ChromeElement. If you build a framework, you can type these elements specifically and give different functionality to the different types of elements. For example, ButtonElement, InputElement, SelectElement, and so on. These elements shouldn't inherit from IWebElement, but instead contain an IWebElement element (the "favor composition over inheritance" principle); besides, inheriting from IWebElement is a giant pain. The constructor of such could either take an IWebElement or an ISearchContext, so you could either find the element with the driver or pass in a By. Frameworks will also allow for greater code reuse. The upfront cost is high but is definitely worth it in the long; you'll write new tests quicker, and the framework itself will require essentially no maintenance.

The second framework is generally the pages you are going to map, the test classes that should correspond to each page class, and an inheritance of "testers" that perform all the functions that get performed in the tests. For example, LoginPage class maps to your login page, which gets tested by LoginPageTests, which inherits from LoginPageTester that contains all page-specific functions, which inherits from BaseTester, which contains functions that will be reused across many different classes of tests. If you're going to have a lot of tests that have to cross multiple pages to complete (not counting Setups of course) then making UtilityTesters that aren't part of the inheritance structure is a great idea. Put all of the functions that the tests will use into these, and give the BaseTester class a reference to all of them. This will make all the functions available to all test classes without making the tests cluttered and difficult to read.

These are just some suggestions for how you can set up your framework, but the one thing that a lot of testers ignore is the idea that tests will require maintenance forever, and it won't always be done by the same person who wrote the tests. Therefore, a lot of your time when first starting to test a new or future application should be spent planning and engineering a great framework that will keep maintenance simple and intuitive, and when writing the tests, above all make their intent easy to understand by naming variables and functions well.


I recently started to write automation test cases for an existing product and after writing just two (badly designed) test cases when I moved over to writing the third one, I realized that I would have to repeat a lot of boiler-plate and other stuff from my first test-case.

So I asked about a week off from testing and designed a test-suite/framework, effectively mapping the website to be tested into C# objects using mainly inheritance of Menus, Sub-Menus and Globally clickable/doable actions; and composition of these objects to represent entire pages that needed testing. By writing generic code for accessing IFrames (that require you to switch focus to and from the IFrame), search filters (on several of the MIS reports with multiple columns and varied options therein) and other getters and setters, after 1 week I was able to quickly deliver the test cases I was working on. Also, the framework got merged with master and all my fellow testers have started working off it (with thanks).

A lot of this framework can (and must preferably) be developed in parallel with the application, since it will not only ensure consistent naming (eg. "id"s) of your IWebElements but also help you test parts of functionality immediately (giving you a considerable speed-up in unit-testing). The resource mapping can follow the same structure as your application structure, thus helping you ensure conformance with your product's design.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.