Glossary

• SUT SYSTEM UNDER TEST
• CUT CLASS UNDER TEST
• MUT METHOD UNDER TEST

Tests without Use of Stub

You do not have to use stub when there are no external dependencies involved in the system under test (SUT). The point is only take it into consideration when you really need it

'''CUT'''

class LogAnalyzer_NoUseStub(object):

    def IsValidLogFileName(self, fileName):

        return str(fileName).endswith('.sln')



''' TEST CASE'''

class LogAnalyzerTestCase(unittest.TestCase):

    # No stub used just simply perform the test

    def test_IsValidLogFileName_BadExtension_ReturnFalse_NoStub(self):

        logAnalyzer0 = LogAnalyzer_0()

        ret = logAnalyzer0.IsValidLogFileName('fn1.sl')

        self.assertFalse(ret)

Tests Must Use Stub

However sometimes we have to rely on the external class or method that we cannot control on it or it has not been finished yet. This is when we need stub to help us. eg, draw_from_weighted_range() and randrange(), interacting with file system. Fakes here include stub (assert on CUT) and mock (assert on Fake) we talk about stub and mock in later posts. Say our IsValidLogFileName() method needs read through the config file and return true if extension is supported in config file.

There two big types to inject fakes into MUT(Method Under Test):

• Test are performed on the MUT itself (eg. assert(mut.dosomething(),true)

• Step 1 - Abstracting concrete objects into interfaces or delegates How: Extract an interface to allow replacing or extending underlying impl

• Step 2 - Refactoring to allow injection of faked implementations of those delegates or interface

  • Inject stub in code under test using factory design (layer of indirection 2 faking a member in factory class) the difference is that the object initiating the stub request is the code under test. the fake instances was set by code external to the code under test before the test started in the below. A test configures the factory class to re turn a stub object. The class uses the factory class to get the stub instance, which in production code would return an object that is not a stub Preferred to using this layer
  • Injection of a stub in test code (layer of indirection 1 faking a member in class under test)
    • Inject stub via ctor (cumbersome whenyou have many dependencies)
    • Inject stub via setter/getter This is much simpler than ctor injection as each test can set only the dependencies that it needs to get the test underway; Use this when you want to signify that the dependency is optional or the dependency has a default instance created that does not create any problems;
    • Inject stub impl via parameter

• Test are performed on the class that inherits from MUT eg. assert(mut_child.dosome). It is also known as Extract and override, which is is good to for simulating inputs into your code under test(in other words, return values from dependency). but it is cumbersome when you want t verify and check interactions that are coming out of the code under test int other dependency (in other words, it is good to play stub but very bad to play mock)

• use local virtual factory method to get instance of stub The time not to use this is there is an interface ready to fake or there is already a place that seam can be injected.

• use extract and override to return a logical result instead of calling an actual dependency This uses a simple faked result instead of a stub Much easier than 2.1 preferred to use