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 somethimes we have to rely on the extenal 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 filesystem. 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
  
  How:

• 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 usess 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 indiretion 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 inhetites from MUT (eg. assert(mut_child.dosomething(),true)
  
  It is also known as Extract and override, which is is good to for sumulating 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 othe 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 denpendency
  
  This uses a simple faked result instead of a stub
  
  Much easier than 2.1 preferred to use