part11.tex

\documentclass[english,serif,mathserif,xcolor=pdftex,dvipsnames,table]{beamer}
\usetheme[informal]{s3it}
\usepackage{s3it}

\title[Testing]{%
  Testing your code
}
\author[S3IT]{%
  S3IT: Services and Support for Science IT, \\
  University of Zurich
}
\date{June~23--24, 2014}

\begin{document}

% title frame
\maketitle


\begin{frame}
  \frametitle{Testing is \textbf{not} a waste of time.}
  A \emph{test} is a piece of code that checks if the code you
  wrote behave as expected.

  \+
  Testing\ldots
  \begin{itemize}
  \item[$\triangleright$] makes sure your code works properly (under given conditions).
  \item[$\triangleright$] ensures changes to the code do not break existing functionality.
  \item[$\triangleright$] forces you to think about unusual conditions and corner cases.
  \end{itemize}

  \+ \textbf{Test Driven Development:} writing tests \textit{before}
  writing the code helps you to write \emph{better code.}
\end{frame}


\begin{frame}
  \frametitle{Different kind of tests}

  There are two kind of tests:

  \+
  \begin{tabular}{>{\em}r>{\raggedright}p{0.75\linewidth}}
    unit tests
    &
    check that a method or class, in isolation,
    actually performs the tasks that it is supposed to do
    \\
    functional tests
    &
    check that the global behavior of an application is the expected one
    \\
  \end{tabular}

  \+
  It's better to have both :-) but we are only going to cover
  only ``unit tests'' here.
\end{frame}


\begin{frame}[fragile]
  \frametitle{Doctest (1/7)}

  The \lstinline|doctest| module searches for text that looks like
  interactive Python sessions in \textit{docstrings}, and then
  executes them to verify that they work exactly as shown.

  \+
  Combines \textit{documentation} and \textit{tests}. Example:
  \begin{lstlisting}
  def square(self, n):
    """
    This function compute the square of a number.

      >>> square(2)
      4
      >>> square(-2)
      4
    """
    return n*n
  \end{lstlisting}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Doctest (2/7)}
  \begin{columns}[t]
    \begin{column}{0.6\textwidth}
  \begin{lstlisting}
def square(x):
    """
    ~\HL{This function compute}~
    ~\HL{the square of a number.}~

      >>> square(2)
      4
    """
  \end{lstlisting}
\end{column}
\begin{column}{0.5\textwidth}
  \raggedleft Line \emph{not} starting with \texttt{>>>} or \emph{not}
  following a line starting with \texttt{>>>} are documentation lines,
  and are thus ignored for testing purposes.
\end{column}
\end{columns}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Doctest (3/7)}
\begin{columns}[t]
  \begin{column}{0.6\textwidth}
  \begin{lstlisting}
def square(x):
    """
    This function compute
    the square of a number.

      ~\HL{>>> square(2)}~
      4
    """
  \end{lstlisting}
\end{column}
\begin{column}{0.4\textwidth}
  \raggedleft
  This line starts with \texttt{>>>}, so it's Python code: it will be
  executed inside a Python shell.
\end{column}
\end{columns}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Doctest (4/7)}
\begin{columns}[t]
  \begin{column}{0.6\textwidth}
  \begin{lstlisting}
def square(x):
    """
    This function compute
    the square of a number.

      >>> square(2)
      ~\HL{4}~
    """
  \end{lstlisting}
\end{column}
\begin{column}{0.4\textwidth}
  \raggedleft
  This line follows a line starting with \texttt{>>>} \emph{and} is
  indented in the same way: it's the output of the previous Python
  statement.
\end{column}
\end{columns}
\end{frame}

\begin{frame}[fragile,fragile]
  \frametitle{Doctest (5/7)}

  To execute all the doctests of module \texttt{foo.py}, run:

  \+
\begin{lstlisting}[language=sh]
$ python -m doctest foo.py
\end{lstlisting}
%$
\end{frame}


\begin{frame}[fragile]
  \frametitle{Doctest (6/7)}

  By default, running doctests only shows failed tests:
\begin{lstlisting}[language=sh,basicstyle=\footnotesize\ttfamily]
$ python -m doctest vector6.py
**********************************************************************
File "vector6.py", line 32, in vector6.Vector
Failed example:
    print v * 2
Expected:
    <2,1>
Got:
    <2,4>
~[\ldots]~
**********************************************************************
1 items had failures:
   2 of  10 in vector6.Vector
***Test Failed*** 2 failures.
\end{lstlisting}
  Otherwise: no output means that all the tests passed.
\end{frame}

\begin{frame}[fragile]
  \frametitle{Doctest (7/7)}

  You can add a \lstinline|-v| option to have a more verbose output
  which includes all the tests executed:
\begin{lstlisting}[language=sh,basicstyle=\ttfamily\scriptsize]
$ python -m doctest -v vector6.py
~[\ldots]~
Trying:
    print v * 2
Expecting:
    <2,4>
ok
5 items had no tests:
    vector6
    vector6.Vector.__add__
    vector6.Vector.__eq__
    vector6.Vector.__init__
    vector6.Vector.__str__
1 items passed all tests:
   2 tests in vector6.Vector.__mul__
**********************************************************************
1 items had failures:
   2 of  10 in vector6.Vector
12 tests in 7 items.
10 passed and 2 failed.
***Test Failed*** 2 failures.
\end{lstlisting}
%$
\end{frame}


\begin{frame}
\+
\begin{exercise}
  The file
  \href{https://raw.github.com/gc3-uzh-ch/python-course/master/vector6.py}{\texttt{vector6.py}}
  has some doctest, but they are wrong. Run the tests, find the errors
  and fix them!
\end{exercise}

\end{frame}


\begin{frame}[fragile]
  \frametitle{The unittest module (1/4)}
  Allows you to create tests in a more structured way using the
  \textit{Template method pattern}.

  \begin{lstlisting}
import unittest

class MyTest(unittest.TestCase):
  def test_square1(self):
    assert square(1) == 1

  def test_square2(self):
    self.assertEqual(square(2), 4)
    self.assertEqual(square(-2), 4)
  \end{lstlisting}

Any method whose name starts with \lstinline|test_| will be run.
A test is successful iff it does \emph{not} raise an exception!

\+
Specialized ``asserts'' are defined in the \lstinline|TestCase|
class: they provide better logging and reporting of failures.
\end{frame}


\begin{frame}[fragile]
  \frametitle{The unittest module (2/4)}

  The \lstinline|unittest.TestCase| class defines some useful methods:
  \begin{tabular}{>{\scriptsize\ttfamily}rp{0.75\linewidth}}
  assertEqual(x,y)           & check that \texttt{x == y} \\
  assertTrue(x)              & check that \texttt{x is True} \\
  assertGreater(x, y)        & check that \texttt{x > y} \\
  assertIsInstance(obj, cls) & check that \texttt{obj} is an instance of \texttt{cls} \\
  \ldots                     & a lot more, cf. \texttt{help(unittest)}
  \end{tabular}

  \+
  Each one of these method is able to print detailed informations on
  why the test failed, this is why you don't just use
  \texttt{assertTrue()} for all the tests\ldots
\end{frame}


\begin{frame}[fragile]
  \frametitle{The unittest module (3/4)}
  Supports \textit{fixtures}, code to run before and/or after each
  test to prepare and cleanup the testing environment.

  \+
  \begin{lstlisting}
import unittest

class MyTest(unittest.TestCase):
  def setUp(self):
    """This code is run *before* each test method."""

  def tearDown(self):
    """This code is run *after* each test method."""
  \end{lstlisting}
\end{frame}


\begin{frame}[fragile]
\frametitle{The unittest module (4/4)}
Run unit tests with:
\+
  \begin{lstlisting}[language=sh]
$ python -m unittest ex10b
....
----------------------------------------------------------------------
Ran 4 tests in 0.000s

OK
\end{lstlisting}
%$
\end{frame}


\begin{frame}[fragile]
  \begin{exercise}
    Write a set of unit tests for the following function:
\begin{lstlisting}
def is_prime(number):
  """Return True if `number` is prime."""
  for element in range(number):
    if number % element == 0:
      return False
  return True
\end{lstlisting}
    Pay special attention to the corner cases!
  \end{exercise}
\end{frame}


\end{document}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End: