How to create and maintain usable methods/function using c#

Experiences, small talk, and other automation gossip.
Posts: 11
Joined: Fri Jul 03, 2015 5:35 pm

How to create and maintain usable methods/function using c#

Post by sunil.pandey » Sun Jul 05, 2015 8:56 pm


My requirement is to create a maintainable automation framework, where I've to create different utility methods page by page.

Example: Support I've 3 pages to automate
1. Login page
2. Home Page
3. Submit Page

So for each page I am going to have separate repository for better maintainability (Please suggest if I should do something else)

Say main page have many buttons and text boxes so I want to create methods for each of them with various operations, as displayed below:

Keep all the methods of main page or any page inside single namespace and single class
class MainPage
1. Click on Home page Next button:

public void ClickHomeNext()

2. Enter Text in the text box, say in Amount text box

public void EnterAmount(int amount)

So please suggest how to organize all above things so that I can call any method any where while writing test script.
Like I can use reference(c#: using Namespace), create object of that class and use any method inside that class

Please suggest?

Best Regards,

User avatar
Posts: 37
Joined: Mon Jun 08, 2015 7:37 am

Re: How to create and maintain usable methods/function using c#

Post by jasoncleo » Wed Jul 08, 2015 3:21 am

Hi Sunil,

Depending on your company's structure, you may find it easier to have a chat with any .Net developers within the group. Failing that though, here are some items that may possibly help you:

For your one AUT product, it may be best to have just the one Ranorex solution, with multiple C# Projects in it.

The structure that is used at my organisation is to have a group of "Common" projects which simply provide a set of user code modules and classes that do common actions. You could essentially have one class per screen of your application. So each class fully understands the UI controls and actions of that particular screen. You can also have separate UI repositories for each screen as well. We opted to have a single one for ourselves, as there was alot of UX revisions, but your company's product may be different.

With the above structure, any change to the UI is then isolated to one class and one UI repository.

You then create separate Ranorex Test Suites (still within the one solution though) for particular components or functional groups, and the user code modules in those test suites then call the common code components to do actions.

The idea of the common code is that it will do all the tedious grunt work.

Code: Select all

public class LoginScreen {
   public bool DoLogin(string username, string password) {
       var repo = YourRepoProject.LoginRepository.Instance;
       // Validation key UI elements are present
       if (!repo.MyApp.LoginScreenInfo.Exists(0) ||
           !repo.MyApp.UsernameInfo.Exists(0) || ... <etc>) {
           throw new Exception("We're not on our expected Login screen.");

       if (!repo.MyApp.Username.Visible || !repo.MyApp.Password.Visible) {
          throw new Exception("The expected controls were not visible.");


       /// etc etc, press login, validate that the credentials were accepted, indicate success.
So the test code may call a method from your common code:

Code: Select all


// Do other actions

// Do a bunch of Validate calls to assess the intended success of  the test.

At the end of the day, your test manager or program manager will define the structure and organisation of your test code. But I think the above approach works well, as your test cases are easier to read and review, and the complex interaction code is centralised in one place (common) to constrain the impact of updates if the AUT should change.

Hope the above helps.