changes in the directory so that it can be compiled by sphinx

6 files changed, 0 insertions, 939 deletions

diff --git a/lecture_notes/test_driven_development/generate_testcases.py b/lecture_notes/test_driven_development/generate_testcases.py
deleted file mode 100644
index 17b48a7..0000000
--- a/lecture_notes/test_driven_development/generate_testcases.py
+++ /dev/null
@@ -1,36 +0,0 @@
-import random
-
-def gcd(a, b):
-    while b != 0:
-        a, b = b, a % b
-    return a
-
-a = random.sample(xrange(100), 10)
-b = random.sample(xrange(1000), 10)
-c = random.sample(xrange(10000), 10)
-c = random.sample(xrange(10000), 10)
-d = random.sample(xrange(100000), 10)
-e = random.sample(xrange(1000000), 10)
-f = a + b + c + d + e
-f.sort()
-a = random.sample(xrange(100), 10)
-b = random.sample(xrange(1000), 10)
-c = random.sample(xrange(10000), 10)
-d = random.sample(xrange(100000), 10)
-e = random.sample(xrange(1000000), 10)
-g = a + b + c + d + e
-
-testcases = []
-for item in f:
-    a = f[random.randrange(0, len(f))]
-    b = g[random.randrange(0, len(g))]
-    gc = gcd(a, b)
-    testcases.append([a, b, gc])
-
-sortedcases = sorted(testcases, key=lambda case: case[0])
-
-fil = open('/home/madhu/Desktop/gcdtest.dat', 'w')
-for case in sortedcases:
-    fil.write('%d, %d, %d\n' % (case[0], case[1], case[2]))
-
-fil.close()
diff --git a/lecture_notes/test_driven_development/lab_workbook.rst b/lecture_notes/test_driven_development/lab_workbook.rst
deleted file mode 100644
index fa5afa4..0000000
--- a/lecture_notes/test_driven_development/lab_workbook.rst
+++ /dev/null
@@ -1,146 +0,0 @@
-======================================
-Lab Workbook - Test Driven Development
-======================================
-
-The notation that follows every question denotes the level on the
-Revised Bloom's Taxonomy.
-
-Lab - 1
-=======
-
-  1. Write a stub function for calculating the LCM of two numbers.
-                                                            - U-level
-  2. Write the tests for the LCM function, place the tests in if
-     __name__ == '__main__': part of the Python file. Demonstrate that
-     the tests fail.                                        - U-level
-  3. Implement the code for the LCM function, using the gcd function
-     provided in the examples in the chapter. Demonstrate the tests
-     pass. (For the algorithm refer to Wikipedia - [0])     - Ap-level
-  4. Alternatively, build a set of test cases, preferably a large
-     number of cases, place it in a text file and use these test cases
-     to test your LCM function. Demonstrate that tests still continue
-     to pass.                                               - U-level
-
-[0] - http://en.wikipedia.org/wiki/Least_common_multiple#Reduction_by_the_greatest_common_divisor
-
-Lab - 2
-=======
-
-  1. Write the stub function, followed by the tests(demonstrating the
-     failed tests), in turn followed by the code(demonstrating the
-     passing tests) to calculate the number of days between two
-     dates. Name your function num_of_days(). The function should take
-     two arguments, both being tuples. Each tuple represents the date
-     in the format of (dd, mm, yyyy) where dd, mm and yyyy are
-     integers.                                              - Ap-level
-
-  2. Rewrite the num_of_days() function to take the start date as an
-     optional argument. If the start date is not specified calculate
-     the number of days between the only specified date since Unix
-     epoch. Prior to manipulating the code to do this, make sure you
-     change the tests, make them fail and then refactor the code.
-                                                            - Ap-level
-
-
-Lab -3
-======
-
-  1. Move the tests that were written to GCD function in the examples
-     of this chapter to a separate function called test_gcd(). Do the
-     same for LCM function and num_of_days() function. Make sure when
-     the respective Python files are executed as stand alone scripts
-     these tests executed.                                  - U-level
-  2. Put all these files in a single directory called utils and run
-     the nosetests command. Make a report of the results.   - U-level
-  3. Write doctests to each of the above functions. Demonstrate and
-     report the results as executed by running the doctests using
-     doctest.testmod() function and using nosetests command. -Ap-level
-
-Lab - 4
-=======
-
-  1. Consider the following use case: We are given a large list of
-     items called *data* where each item is a again a list with three
-     values: username, which is a string; status of the user which
-     can be one of the following three strings 'new', 'valid' or
-     'invalid'; and the last login time which is a datetime Python
-     object.  Write a function called **query** that takes a filter
-     dictionary as a parameter and returns the result of the items in
-     the *data* list. They keys of the dictionary can be 'user',
-     'status' and 'logtime' and their corresponding values can be any
-     of the valid values for the corresponding key. Example filter
-     dictionary::
-
-       filter = {
-           'user': 'john'
-           'status': 'new'
-           }
-
-     Place your function in a file called query.py. Before writing the
-     actual function, follow the test driven development
-     approach. First write a stub, fail the tests and then write the
-     code and make sure the tests pass. Specifically use unittest
-     framework to test this function. Place your tests in a file
-     called test_query.py
-
-     A developer wrote a small utility function in a file named
-     user_utils.py which uses your **query** function which looks as
-     follows::
-
-       def login_util(user=None):
-           """Takes a user name and returns his last login time if the
-           user is a valid user, else return None. If the user is
-           'host' it returns the last login time of all the users.
-           """
-
-           filter_dict = {
-               'user': user
-               'status': 'active'
-               }
-
-           if user == 'host':
-               filter_dict['status'] + ['new', 'invalid']
-
-           return query(filter_dict)
-
-     Unfortunately the developer did not provide us with the test
-     cases. We wrote the following test cases for you to only discover
-     that the function miserably fails. 
-
-     The tests were placed in a file called test_user_utils.py and we
-     have used the unittest framework::
-
-       import query
-       import user_utils
-       import unittest
-
-       class TestUserUtils(unittest.TestCase):
-        
-           def setUp(self):
-               """Boiler plate method to provide common data to all
-               the test methods.
-               """
-               self.test_names = ['Alex', 'Guido', 'Thomas', 'host',
-                   'Tom', 'James']
-               self.data_len = len(query.data)
-
-           def test_login_utils(self):
-               """Tests for the login_utils function.
-               """
-
-               for name in self.test_names:
-                   if name == 'host':
-                       assertEqual(len(user_utils.login_utils(name)), self.data_len)
-                   else:
-                       assertLess(len(user_utils.login_utils(name)), self.data_len)
-
-           def tearDown(self):
-               """Boiler plate method to clean up all the data created
-               for tests.
-               """
-
-               del self.test_names
-               del self.data_len
-
-     Fix the bug, run the tests to make sure the function passes the
-     tests and if possible refactor the code with a better approach. - An-level
diff --git a/lecture_notes/test_driven_development/math_utils/gcd.py b/lecture_notes/test_driven_development/math_utils/gcd.py
deleted file mode 100644
index 7204ac0..0000000
--- a/lecture_notes/test_driven_development/math_utils/gcd.py
+++ /dev/null
@@ -1,22 +0,0 @@
-def gcd(a, b):
-    """Returns the Greatest Common Divisor of the two integers
-    passed as arguments.
-
-    Args:
-      a: an integer
-      b: another integer
-
-    Returns: Greatest Common Divisor of a and b
-
-    >>> gcd(48, 64)
-    16
-    >>> gcd(44, 19)
-    1
-    """
-    if b == 0:
-        return b
-    return gcd(b, a%b)
-
-if __name__ == "__main__":
-    import doctest
-    doctest.testmod()
diff --git a/lecture_notes/test_driven_development/math_utils/gcd_testcases.dat b/lecture_notes/test_driven_development/math_utils/gcd_testcases.dat
deleted file mode 100644
index 3829b12..0000000
--- a/lecture_notes/test_driven_development/math_utils/gcd_testcases.dat
+++ /dev/null
@@ -1,50 +0,0 @@
-6, 22, 2
-6, 48744, 6
-14, 143295, 1
-22, 751, 1
-35, 79, 1
-35, 96, 1
-52, 12, 4
-73, 79, 1
-73, 184790, 1
-86, 11, 1
-93, 8, 1
-93, 798, 3
-113, 42785, 1
-209, 2135, 1
-395, 8989, 1
-587, 331, 1
-643, 751, 1
-721, 242525, 1
-733, 5622, 1
-854, 42785, 1
-1695, 57, 3
-1695, 798, 3
-3429, 177203, 1
-4603, 12, 1
-4603, 48744, 1
-6139, 57, 1
-6139, 204, 1
-6660, 96, 12
-6660, 410400, 180
-6703, 410400, 1
-8964, 22, 2
-9673, 751, 1
-9673, 7909, 1
-9673, 3335, 1
-16028, 891, 1
-44231, 378, 1
-49020, 751, 1
-57908, 184790, 2
-65482, 548045, 1
-79715, 8, 1
-79715, 891, 1
-79715, 66371, 1
-321807, 891, 3
-366607, 97, 1
-402212, 5595, 1
-448426, 66371, 1
-575271, 4617, 9
-575271, 402152, 1
-680256, 48744, 72
-779565, 184790, 5
diff --git a/lecture_notes/test_driven_development/math_utils/test_gcd.py b/lecture_notes/test_driven_development/math_utils/test_gcd.py
deleted file mode 100644
index c81c72b..0000000
--- a/lecture_notes/test_driven_development/math_utils/test_gcd.py
+++ /dev/null
@@ -1,29 +0,0 @@
-import gcd
-import unittest
-
-class TestGcdFunction(unittest.TestCase):
-
-    def setUp(self):
-        self.test_file = open('gcd_testcases.dat')
-        self.test_cases = []
-        for line in self.test_file:
-            values = line.split(', ')
-            a = int(values[0])
-            b = int(values[1])
-            g = int(values[2])
-
-            self.test_cases.append([a, b, g])
-
-    def test_gcd(self):
-        for case in self.test_cases:
-            a = case[0]
-            b = case[1]
-            g = case[2]
-            self.assertEqual(gcd.gcd(a, b), g)
-
-    def tearDown(self):
-        self.test_file.close()
-        del self.test_cases
-
-if __name__ == '__main__':
-    unittest.main()
diff --git a/lecture_notes/test_driven_development/tdd.rst b/lecture_notes/test_driven_development/tdd.rst
deleted file mode 100644
index 6347c47..0000000
--- a/lecture_notes/test_driven_development/tdd.rst
+++ /dev/null
@@ -1,656 +0,0 @@
-=======================
-Test Driven Development
-=======================
-
-What is TDD?
-============
-
-Objectives
-----------
-At the end of this section, you will be able to:
-
-1. Write your code using the TDD paradigm. 
-#. Use doctests to test your Python code. 
-#. Use unittests to test your Python code. 
-#. Use the nose module to test your code. 
-
-
-Test Driven Development (TDD), as the name suggests, is a style or method
-of software development based on the idea of writing code, after writing
-tests for them. As the tests are written for code, that doesn't even exist
-yet, it is bound to fail. Actual code is later written, to pass the test
-and later on refactored.
-
-The basic steps of TDD are roughly as follows - 
-
-1. Decide upon the feature to implement and the methodology of testing it. 
-#. Write the tests for the feature decided upon. 
-#. Just write enough code, so that the test can be run, but it fails. 
-#. Improve the code, to just pass the test and at the same time passing all
- previous tests. 
-#. Run the tests to see, that all of them run successfully. 
-#. Refactor the code we've just written -- optimize the algorithm, remove
- duplication, add documentation, etc. 
-#. Run the tests again, to see that all the tests still pass. 
-#. Go back to 1. 
-
-First "Test"
-============
-
-Now, that we have an overview of TDD, let's get down to writing our first
-test. Let us consider a very simple program which returns the Greatest
-Common Divisor (GCD) of two numbers. 
-
-Before being able to write our test, we need to have a clear idea of the
-code units our program will contain, so that we can test each of them.
-Let's first define the code units that our GCD program is going to have. 
-
-Our program is going to contain only one function called ``gcd``, which
-will take in two arguments, and return a single value, which is the GCD of
-the two arguments. So if we want to find out GCD of 44, 23, we call the
-function, with the arguments 44 and 23. 
-
-::
-
-    c = gcd(44, 23) 
-
-c will contain the GCD of the two numbers.
-
-We have defined the code units in our program. So, we can go ahead and
-write tests for it. 
-
-When adopting the TDD methodology, it is important to have a clear set of
-results defined for our code units i.e., for every given set of inputs as
-that we wish use as a test case, we must have, before hand, the exact
-outputs that are expected for those input test cases. We must not be
-running around looking for outputs for our test cases after we have the
-code ready, or even while we are writing the tests.
-
-Let one of our test cases be 48 and 64 as ``a`` and ``b``, respectively.
-For this test case we know that the expected output, the GCD, is 16. Let
-our second test case be 44 and 19 as ``a`` and ``b``, respectively. We know
-that their GCD is 1, and that is the expected output. 
-
-But before writing one, we should What does a test look like? What does it
-do? Let's answer this question first.
-
-Tests are just a series of assertions which are either True or False
-depending on the expected behaviour of the code and the actual behaviour.
-Tests for out GCD function could be written as follows.
-
-::
-
-  tc1 = gcd(48, 64)
-  if tc1 != 16:
-      print "Failed for a=48, b=64. Expected 16. Obtained %d instead." % tc1
-      exit(1)
-  
-  tc2 = gcd(44, 19)
-  if tc2 != 1:
-      print "Failed for a=44, b=19. Expected 1. Obtained %d instead." % tc2
-      exit(1)
-
-  print "All tests passed!"
-
-The next step is to run the tests we have written, but if we run the tests
-now, the tests wouldn't even run. Why? We don't even have the function
-``gcd`` defined, for it to be called by the tests. The test code doesn't
-even run! What is the way out? We shall first write a very minimal
-definition (or a stub) of the function ``gcd``, so that it can be called by
-the tests.
-
-A minimal definition for the ``gcd`` function would look like this
-
-::
-
-    def gcd(a, b):
-        pass
-
-As you can see, the stub for ``gcd`` function does nothing, other than
-define the required function which takes the two arguments a and b. No
-action is done upon the arguments, passed to the function, yet. The
-function definition is empty and just contains the ``pass`` statement. 
-
-Let us put all these in a file and call this file ``gcd.py`` 
-
-::
-
-  def gcd(a, b):
-      pass
-
-  if __name__ == '__main__':
-      tc1 = gcd(48, 64)
-      if tc1 != 16:
-          print "Failed for a=48 and b=64. Expected 16. Obtained %d instead." % tc1
-          exit(1)
-
-      tc2 = gcd(44, 19)
-      if tc2 != 1:
-          print "Failed for a=44 and b=19. Expected 1. Obtained %d instead." % tc2
-          exit(1)
-
-      print "All tests passed!"
-
-Recall that, the condition ``__name__ == '__main__'`` becomes true, only
-when the python script is ran directly as a stand-alone script. So any code
-within this ``if`` block is executed only when the script is run as a
-stand-alone script and doesn't run when it is used as a module and
-imported.
-
-Let us run our code as a stand-alone script.
-
-::
-
-  $ python gcd.py
-  Traceback (most recent call last):
-    File "gcd.py", line 7, in <module> print "Failed for a=48 and b=64. Expected 16. Obtained %d instead." % tc1
-  TypeError: %d format: a number is required, not NoneType
-
-We now have our tests, the code unit stub, and a failing test. The next
-step is to write code, so that the test just passes. 
-
-Let's us the algorithm given by a greek mathematician, 2300 years ago, the
-Euclidean algorithm, to compute the GCD of two numbers. 
-
-**Note**: If you are unaware of Euclidean algorithm to compute the gcd of
-two numbers please refer to it on wikipedia. It has a very detailed
-explanation of the algorithm and its proof of validity among other things.
-
-The ``gcd`` stub function can be modified to the following function, 
-
-::
-
-    def gcd(a, b):
-        if a == 0:
-            return b
-        while b != 0:
-            if a > b:
-                a = a - b
-            else:
-                b = b - a
-        return a
-
-Now let us run our script which already has the tests written in it and see
-what happens
-
-::
-
-    $ python gcd.py
-    All tests passed!
-
-Success! We managed to write code, that passes all the tests. The code we
-wrote was simplistic, actually. If you take a closer look at the code you
-will soon realize that the chain of subtraction operations can be replaced
-by a modulo operation i.e. taking remainders of the division between the
-two numbers since they are equivalent operations. The modulo operation is
-far better, since it combines a lot of subtractions into one operation and
-the reduction is much faster. Take a few examples, and convince yourself
-that using the modulo operation is indeed faster than the subtraction
-method.
-
-::
-
-    def gcd1(a, b):
-        while b != 0 and a != 0:
-            if a > b:
-                a = a%b
-            else:
-                b = b%a
-        if a == 0:
-            return b
-        else:
-            return a
-
-But we know that the modulo of ``a%b`` is always less than b. So, if the
-condition ``a>b`` is True in this iteration, it will definitely be False in
-the next iteration. Also note that , and in the case when ``a < b``,
-``a%b`` is equal to ``a``. So, we could, essentially, get rid of the
-``if-else`` block and combine a swapping operation along with the modulo
-operation. 
-
-::
-
-    def gcd(a, b):
-        while b != 0:
-            a, b = b, a % b
-        return a
-
-Let's run our tests again, and check that all the tests are passed, again.
-
-We could make one final
-improvement to our ``gcd`` function, which is strictly not necessary in
-terms of efficiency, but is definitely more readable and easy to
-understand. We could make our function a recursive function, as shown below
-
-::
-
-  def gcd(a, b):
-      if b == 0:
-          return a
-      return gcd(b, a%b)
-
-Much shorter and sweeter! We again run all the tests, and check that they
-are passed. It indeed does pass all the tests! 
-
-But there is still one small problem. There is no way, for the users of
-this function, to determine how to use it, how many arguments it takes and
-what it returns, among other things. This is a handicap for the people
-reading your code, as well. This is well written function, with no
-documentation whatsoever. 
-
-Let's add a docstring as shown,
-
-::
-
-    def gcd(a, b):
-        """Returns the Greatest Common Divisor of the two integers
-        passed as arguments.
-  
-        Args:
-          a: an integer
-          b: another integer
-  
-        Returns: Greatest Common Divisor of a and b
-        """
-        if b == 0:
-            return a
-        return gcd(b, a%b)
-
-Now we have refactored our code enough to make it well written piece
-of code. We have now successfully completed writing our first test, writing
-the relevant code, ensuring that the tests are passed and refactoring the
-code, until we are happy with the way it works and looks. 
-
-Let's now build on what we have learnt so far and learn more about writing
-tests and improve our methodology of writing tests and simplify the process
-of writing them. 
-
-Persistent Test Cases
----------------------
-
-As already stated, tests should be predetermined and you should have your
-test cases and their outputs ready, even before you write the first line of
-code. This test data is repeatedly used in the process of writing code. So,
-it makes sense to have the test data to be stored in some persistent format
-like a database, a text file, a file of specific format like XML, etc.
-
-Let us modify the test code for the GCD function and save our test data in
-a text file. Let us decide upon the following format for the test data. 
-
-  1. The file has multiple lines of test data.
-  2. Each line in this file corresponds to a single test case.
-  3. Each line consists of three comma separated values --
-
-     i. First two coloumns are the integers for which the GCD has to
-        be computed
-     ii. Third coloumn is the expected GCD to the preceding two
-         numbers.
-
-Now, how do we modify our tests to use this test data? We read the file
-line by line and parse it to obtain the required numbers whose GCD we wish
-to calculate, and the expected output. We can now call the ``gcd`` function
-with the correct arguments and verify the output with the expected output. 
-
-Let us call our data file ``gcd_testcases.dat``
-
-::
-
-    if __name__ == '__main__':
-        for line in open('gcd_testcases.dat'):
-            values = line.split(', ')
-            a = int(values[0])
-            b = int(values[1])
-            g = int(values[2])
-  
-            tc = gcd(a, b)
-            if tc != g:
-                print "Failed for a=%d and b=%d. Expected %d. Obtained %d instead." % (a, b, g, tc)
-                exit(1)
-
-        print "All tests passed!"
-
-When we execute the gcd.py script again we will notice that the code passes
-all the tests. 
-
-Now, we have learnt how to write simple test cases and develop code based
-on these test cases. We shall now move on to learn to use some testing
-frameworks available for Python, which make some of the task easier. 
-
-Python Testing Frameworks
-=========================
-
-Python provides two ways to test the code we have written. One of them is
-the unittest framework and the the other is the doctest module. To start
-with, let us discuss the doctest module.
-
-doctest
-~~~~~~~
-
-As we have already discussed, a well written piece of code must always be
-accompanied by documentation. We document functions or modules using
-docstrings. In addition to writing a generic description of the function or
-the module, we can also add examples of using these functions in the
-interactive interpreter to the docstrings. 
-
-Using the ``doctest`` module, we can pick up all such interactive session
-examples, execute them, and determine if the documented piece of code runs,
-as it was documented. 
-
-The example below shows how to write ``doctests`` for our ``gcd`` function.
-
-::
-
-    def gcd(a, b):
-        """Returns the Greatest Common Divisor of the two integers
-        passed as arguments.
-  
-        Args:
-          a: an integer
-          b: another integer
-  
-        Returns: Greatest Common Divisor of a and b
-  
-        >>> gcd(48, 64)
-        16
-        >>> gcd(44, 19)
-        1
-        """
-        if b == 0:
-            return a
-        return gcd(b, a%b)
-
-That is all there is, to writing a ``doctest`` in Python. Now how do we use
-the ``doctest`` module to execute these tests. That too, is fairly straight
-forward. All we need to do is tell the doctest module to execute, using the
-``doctest.testmod`` function. 
-
-Let us place this piece of code at the same place where we placed our tests
-earlier. So putting all these together we have our ``gcd.py`` module which
-looks as follows
-
-::
-
-    def gcd(a, b):
-        """Returns the Greatest Common Divisor of the two integers
-        passed as arguments.
-  
-        Args:
-          a: an integer
-          b: another integer
-  
-        Returns: Greatest Common Divisor of a and b
-  
-        >>> gcd(48, 64)
-        16
-        >>> gcd(44, 19)
-        1
-        """
-        if b == 0:
-            return a
-        return gcd(b, a%b)
-  
-    if __name__ == "__main__":
-        import doctest
-        doctest.testmod()
-
-The ``testmod`` function automatically picks up all the docstrings that
-have sample sessions from the interactive interpreter, executes them and
-compares the output with the results as specified in the sample sessions.
-If all the outputs match the expected outputs that have been documented, it
-doesn't say anything. It complains only if the results don't match as
-documented, expected results. 
-
-When we execute this script as a stand-alone script we will get back the
-prompt with no messages which means all the tests passed
-
-::
-
-    $ python gcd.py
-    $ 
-
-If we further want to get a more detailed report of the tests that were
-executed we can run python with -v as the command line option to the script
-
-::
-
-  $ python gcd.py -v
-  Trying:
-      gcd(48, 64)
-  Expecting:
-    16
-  ok
-  Trying:
-      gcd(44, 19)
-  Expecting:
-      1
-  ok
-  1 items had no tests:
-      __main__
-  1 items passed all tests:
-     2 tests in __main__.gcd
-  2 tests in 2 items.
-  2 passed and 0 failed.
-  Test passed.
-
-
-**Note:** We can have the sample sessions as test cases as long as the
-outputs of the test cases do not contain any blank lines. In such cases we
-may have to use the exact string ``<BLANKLINE>``
-
-For the sake of illustrating a failing test case, let us assume that we
-made a small mistake in our code. Instead of returning ``a`` when b = 0, we
-typed it as ``return b`` when b = 0. Now, all the GCDs returned will have
-the value 0. The code looks as follows
-
-::
-
-    def gcd(a, b):
-        """Returns the Greatest Common Divisor of the two integers
-        passed as arguments.
-  
-        Args:
-          a: an integer
-          b: another integer
-  
-        Returns: Greatest Common Divisor of a and b
-  
-        >>> gcd(48, 64)
-        16
-        >>> gcd(44, 19)
-        1
-        """
-        if b == 0:
-            return b
-        return gcd(b, a%b)
-
-Executing this code snippet without -v option to the script
-
-::
-
-  $ python gcd.py
-  **********************************************************************
-  File "gcd.py", line 11, in __main__.gcd
-  Failed example:
-      gcd(48, 64)
-  Expected:
-      16
-  Got:
-      0
-  **********************************************************************
-  File "gcd.py", line 13, in __main__.gcd
-  Failed example:
-      gcd(44, 19)
-  Expected:
-      1
-  Got:
-      0
-  **********************************************************************
-  1 items had failures:
-     2 of   2 in __main__.gcd
-  ***Test Failed*** 2 failures.
-
-The output clearly complains that there were exactly two test cases
-that failed. If we want a more verbose report we can pass -v option to
-the script. 
-
-This is all there is, to using the ``doctest`` module in Python.
-``doctest`` is extremely useful when we want to test each Python function
-or module individually. 
-
-For more information about the doctest module refer to the Python library
-reference on doctest[0].
-
-unittest framework
-~~~~~~~~~~~~~~~~~~
-
-We needn't go too far ahead, to start complaining that ``doctest`` is not
-sufficient to write complicated tests especially when we want to automate
-our tests, write tests that need to test for more convoluted code pieces.
-For such scenarios, Python provides a ``unittest`` framework.
-
-The ``unittest`` framework provides methods to efficiently automate tests,
-easily initialize code and data for executing the specific tests, cleanly
-shut them down once the tests are executed and easy ways of aggregating
-tests into collections and better way of reporting the tests.
-
-Let us continue testing our gcd function in the Python module named
-``gcd.py``. The ``unittest`` framework expects us to subclass the
-``TestCase`` class in ``unittest`` module and place all our test code as
-methods of this class. The name of the test methods are expected to be
-started with ``test_``, so that the test runner knows which methods are to
-be executed as tests. We shall use the test cases supplied by
-``gcd_testcases.dat``. 
-
-Lastly, to illustrate the way to test Python code as a module, let's create
-a new file called ``test_gcd.py`` following the same convention used to
-name the test methods, and place our test code in it. 
-
-::
-  
-    import gcd
-    import unittest
-  
-    class TestGcdFunction(unittest.TestCase):
-  
-        def setUp(self):
-            self.test_file = open('gcd_testcases.dat')
-            self.test_cases = []
-            for line in self.test_file:
-                values = line.split(', ')
-                a = int(values[0])
-                b = int(values[1])
-                g = int(values[2])
-  
-                self.test_cases.append([a, b, g])
-  
-        def test_gcd(self):
-            for case in self.test_cases:
-                a = case[0]
-                b = case[1]
-                g = case[2]
-                self.assertEqual(gcd.gcd(a, b), g)
-  
-        def tearDown(self):
-            self.test_file.close()
-            del self.test_cases
-  
-    if __name__ == '__main__':
-        unittest.main()
-
-Please note that although we highly recommend writing docstrings for all
-the classes, functions and modules, we have not done so, in this example to
-keep it compact. Adding suitable docstrings wherever required is left to
-you, as an exercise. 
-
-It would be a waste, to read the test data file, each time we run a test
-method. So, in the setUp method, we read all the test data and store it
-into a list called test_cases, which is an attribute of the TestGCDFunction
-class. In the tearDown method of the class we will delete this attribute to
-free up the memory and close the opened file.
-
-Our actual test code sits in the method which begins with the name
-``test_``, as stated earlier, the ``test_gcd`` method. Note that, we import
-the ``gcd`` Python module we have written at the top of this test file and
-from this test method we call the ``gcd`` function within the ``gcd``
-module to be tested with the each set of ``a`` and ``b`` values
-``test_cases``. Once we execute the ``test_gcd`` function, we obtain the
-result and compare it with the expected result as stored in the
-corresponding ``test_cases`` attribute using the ``assertEqual`` method
-provided by ``TestCase`` class in the ``unittest`` framework. There are
-several other assertion methods supplied by the unittest framework. For a
-more detailed information about this, refer to the unittest library
-reference at [1]. This brings us to the end of our discussion of the
-``unittest`` framework. 
-
-nose
-====
-
-We have seen the ``unittest`` frame work and Python ``doctest`` module. .
-One problem however remains. It is not easy to organize, choose and run
-tests, when our code is scattered across multiple files. In the real world
-scenario, this is often the case. 
-
-In such a such a scenario, a tool which can aggregate these tests
-automatically, and run them. The ``nose`` module, does precisely this, for
-us. It can aggregate ``unittests`` and ``doctests`` into a collection and
-run them. It also helps output the test-results and aggregate them in
-various formats.
-
-Although nose is not part of the standard Python distribution itself, it
-can be very easily installed by using easy_install command as follows
-
-::
-
-  $ easy_install nose
-
-Or download the nose package from [2], extracting the archive and running
-the command from the extracted directory
-
-::
-
-  $ python setup.py install
-
-Now we have nose up and running, but how do we use it? We shall use the
-``nosetests``  command provided by the ``nose`` module, in the top-level
-directory of our code. 
-
-::
-
-  $ nosetests
-
-That's all! ``nose`` will now automatically pick all the tests in all the
-directories and subdirectories in our code base and execute them.
-
-However if we want to execute specific tests we can pass the test file
-names or the directories as arguments to nosetests command. For a detailed
-explanation about this, refer to [3]
-
-Conclusion
-==========
-
-Now we have all the trappings we want to write state-of-the art tests. To
-emphasize the same point again, any code which was written before writing
-the test and the testcases in hand is flawed by design. So it is
-recommended to follow the three step approach while writing code for any
-project as below:
-
-  1. Write failing tests with testcases in hand.
-  2. Write the code to pass the tests.
-  3. Refactor the code for better performance.
-
-This approach is very famously known to the software development world as
-"Red-Green-Refactor" approach[4].
-
-[0] - http://docs.python.org/library/doctest.html
-[1] - http://docs.python.org/library/unittest.html
-[2] - http://pypi.python.org/pypi/nose/
-[3] - http://somethingaboutorange.com/mrl/projects/nose/0.11.2/usage.html
-[4] - http://en.wikipedia.org/wiki/Test-driven_development
-
-.. 
-   Local Variables:
-   mode: rst
-   indent-tabs-mode: nil
-   sentence-end-double-space: nil
-   fill-column: 75
-   End: