Question

I can’t figure out how to design classes in my system.

In classA I create object selenium (it simulates user actions at website).

In this ClassA I create another objects like SearchScreen, Payment_Screen and Summary_Screen.

# -*- coding: utf-8 -*-
from selenium import selenium
import unittest, time, re

class OurSiteTestCases(unittest.TestCase):
    def setUp(self):
        self.verificationErrors = []

        self.selenium = selenium("localhost", 5555, "*chrome", "http://www.someaddress.com/")
        time.sleep(5)
        self.selenium.start()        

    def test_buy_coffee(self):

        sel = self.selenium

        sel.open('/')
        sel.window_maximize()

        search_screen=SearchScreen(self.selenium)
        search_screen.choose('lavazza')

        payment_screen=PaymentScreen(self.selenium)
        payment_screen.fill_test_data()

        summary_screen=SummaryScreen(selenium)
        summary_screen.accept()


    def tearDown(self):
        self.selenium.stop()
        self.assertEqual([], self.verificationErrors)

if __name__ == "__main__":
    unittest.main()

It’s example SearchScreen module:

class SearchScreen:
    def __init__(self,selenium):
        self.selenium=selenium

    def search(self):
        self.selenium.click('css=button.search')

I want to know if there is anything ok with a design of those classes?

Answer 1

Your approach is fine. You have a set of tool classes, each of which needs to know its target. Then you have a toolkit class that coordinates these tools on a particular target.

class AgreePrice:
    def __init__(self, connection): ...

class PlaceOrder:
    def __init__(self, connection): ...

class ConfirmAvailability:
    def __init__(self, connection): ...

class BookingService:
    def __init__(self, connection): ...

    def book(self): 
        for Command in (ConfirmAvailability, AgreePrice, PlaceOrder):
            command = Command(self.connection)
            command.run()
            assert command.success()

There’s nothing at all wrong with those kinds of class structures, in fact they come up all the time, and are a reasonably good design when the individual ‘tool’ classes can’t be placed conveniently in one function.

If ever you find yourself with a class that has tens of methods in it, of which many can be grouped according to specific tasks, this is a good refactor.

As a general rule you want to make sure that your ‘tool’ classes (SearchScreen, etc) are at a conceptually lower level than your controller (your test cases). Which they are for you.

At their simplest these tool classes are a form of the Function Object design pattern. Although in your case, you are calling more than just one method on each object, so they are a little more sophisticated.

---

Or, in short. Your design is fine, and very common.