{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# Test\n",
    "- coders/software engineers spend as much time debugging and testing their codes as they spend on developing/writing the codes\n",
    "- \"To err is human, but to preserve in error is diabolic.\" - anonymous\n",
    "- this more than two thousand-years old proverb fits with coding\n",
    "- \"Progam testing can be used to show the presence of bugs, but never to show their absence!\" - Edsger W. Dijkstra\n",
    "- code coverage is used to measure the degree to which the source code of a program is executed when a particular test suite runs\n",
    "- various coverage criteria:\n",
    "    - function coverage\n",
    "    - statement coverage\n",
    "    - branch coverage\n",
    "    - condition coverage\n",
    "    - loop coverage\n",
    "    - data-flow coverage\n",
    "    - function entry/exit coverage\n",
    "- full path coverage is usually impractical or impossible; module with a succession of n decision in it can have up to 2<sup>n</sup> paths; loops can result in an infinite number of path\n"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## test-driven development\n",
    "- write test cases before or simultaneously along with the code implementation\n",
    "- 3 simple ways to test your code natively at the functional level\n",
    "    1. assert statements - natively supported in many languages; as we've used before\n",
    "    2. doctest - simple, interactive technique, but makes the source code look messy, as they're defined inside the same function and module\n",
    "    3. unittest - preferred; separates the code with test "
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## doctest\n",
    "- https://docs.python.org/3/library/doctest.html\n",
    "- to check that a module’s docstrings are up-to-date by verifying that all interactive examples still work as documented.\n",
    "- to perform regression testing by verifying that interactive examples from a test file or a test object work as expected.\n",
    "- to write tutorial documentation for a package, liberally illustrated with input-output examples. Depending on whether the examples or the expository text are emphasized, this has the flavor of “literate testing” or “executable documentation”."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### see factorial.py in utility package for doctest example"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## unittest\n",
    "- https://docs.python.org/dev/library/unittest.html#module-unittest\n",
    "\n",
    "### see fib_unittest.py in utility package for unittest example"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### exercise\n",
    "1. Write unittest to test functions in utility/factorial.py module."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "collapsed": true
   },
   "outputs": [],
   "source": []
  }
 ],
 "metadata": {
  "kernelspec": {
   "display_name": "Python 3",
   "language": "python",
   "name": "python3"
  },
  "language_info": {
   "codemirror_mode": {
    "name": "ipython",
    "version": 3
   },
   "file_extension": ".py",
   "mimetype": "text/x-python",
   "name": "python",
   "nbconvert_exporter": "python",
   "pygments_lexer": "ipython3",
   "version": "3.6.2"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 2
}