{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# 19 Unit Test\n",
    "<a href=\"https://colab.research.google.com/github/rambasnet/FDSPython-Notebooks/blob/master/Ch19-UnitTest.ipynb\" target=\"_parent\"><img src=\"https://colab.research.google.com/assets/colab-badge.svg\" alt=\"Open In Colab\"/></a>\n",
    "\n",
    "## Topics\n",
    "- unit testing\n",
    "- test-driven development\n",
    "- doctest\n",
    "\n",
    "## 19.1 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",
    "- \"Program 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\n",
    "    - module with a succession of $n$ decision in it can have up to $2^n$ paths\n",
    "    - loops can result in an infinite number of paths\n",
    "- see this repository for more examples of unit testing: https://github.com/rambasnet/KattisDemos"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## 19.2 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": [
    "## 19.3 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": [
    "## 19.4 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": [
    "## 19.5 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.7.3"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 2
}