Writing the Framework

It is in this part of the series that  you will start actually writing code.  If you are somewhat new to coding in C# and using Selenium, I recommend writing out all the code snippets from scratch rather than copying and pasting them, for some of the following reasons;

  • As you start writing code, you will start picking up on patterns in the code, which will help you pick up things quicker
  • As you write out the code and try to reference certain libraries, if you are using ReSharper then Visual Studio IDE will autosuggest libraries to reference and use as you type out your code 😀

Utils.Selenium namespace

Editing the ‘Driver.cs’ class file

  1. Open up the ‘Driver.cs’ class file in the ‘Utils.Selenium’ folder and edit the class file to match like below, which creates a public WebDriver instance that returns DriverController when initiated, which can then have its functionality used in test methods (e.g. maximising the browser() window or implicit/explicit waits etc)…

Editing the ‘Settings.cs’ class file

  1. Open up the ‘Settings.cs’ class file in the ‘Utils.Selenium’ namespace and edit the class file to match like below.  We will be using the Settings file to store public static variables that we will want to be using in our project.  For the purposes of this course, I will be explaining how to automate a simple Google search, therefore I will set my baseUrl to google.com…

Utils.Hooks namespace

Editing the ‘SpecFlowHooks.cs’ class file

  1. Open up the ‘SpecFlowHooks.cs’ class file in the ‘Utils.Hooks’ namespace and edit the class file to match like below, which contains all our SpecFlow hooks for things we want to happen before and/or after an individual SpecFlow scenario is run, dependant of the tags we use above a scenario (e.g. “Chrome”, “Firefox” or “Debug”)…

    The above stops the WebDriver after the scenario has finished running if the tag associated with it is “Chrome” or “Firefox”, but if it is “Debug” then it does not stop the WebDriver, so that the point of failure can be viewed and debugged accordingly

Editing the ‘TestRunHooks.cs’ class file

  1. Open up the ‘TestRunHooks.cs’ class file and edit the file to match like below, which again prevents the WebDriver from stopping when the tag “Debug” is used…

Pages namespace

Editing the ‘BasePage.cs’ class file

  1. Open up the ‘BasePage.cs’ class file in the ‘Pages’ namespace and edit the class file to match like below.  The ‘BasePage’ class is where we will later put all our test methods for our BaseScenarios, as well as any methods that exist and/or can be shared across more than one specific page class (e.g. main navigation, validate a given pageUrl etc)…

Steps namespace (Step Definitions)

Editing the ‘BaseSteps.cs’ class file

  1. Open up the ‘BaseSteps.cs’ class file in the ‘Steps’ namespace and edit it to match like below…
  2. Do similar for the other Step Definition class files

The core framework is now setup! In the next part, we will see how to create our Base Scenarios.

Digiprove sealCopyright secured by Digiprove © 2018
Liked it? Take a second to support Thomas on Patreon!

Previous Article

Next Article

2 Replies to “Part 3. Writing the Framework”

  1. Hello, I was curious as to why the else if debug clause in the ScenarioHooks.cs only starts chrome and the else statement only starts chrome as well. How is it handling debug if the script is using the firefox?

    1. Hi Kyle, good catch. Currently the debug clause is not handling Firefox. The debug clause just uses Chrome as an example in the blog and keeps the webdriver open if the @Debug tag is used. You could maybe add separate @DebugChrome or @DebugFirefox clauses for each browser respectively. The else statement at the end just uses Chrome as the ‘default’ browser to open if no tags were specified, and will NOT keep the webdriver open in that case. Hope that helps a bit.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.