Changeset 173 for docs/trunk/hacking-guide

Legend:

Unmodified

Added

Removed

• docs/trunk/hacking-guide/tock-intro.tex

  r172	r173
  37	37	\section{Add Your Own Code}
  38	38
  39	(追記) %TODO explan any coding conventions (readability over all else?) (追記ここまで)
  40	(追記) (追記ここまで)
  39	41	\section{Test Your Code}
  40	42
  …	…
  45	47	and the function seems to be helpful.
  46	48
  47	We use two test frameworks in Tock; QuickCheck and HUnit. For almost all your tests, HUnit will be the most
  48	appropriate. The main HUnit data type is as follows:
  49	We effectively use four test frameworks in Tock:
  50
  51	\begin{enumerate}
  52	\item QuickCheck; a framework used to generate random input data for tests, then test properties of its output.
  53	\item HUnit; a simple framework for providing standard lists of assertions.
  54	\item CGtests; the standard occam test-suite. Useful for providing a full-system test for anything that gets
  55	used in the occam side of things. Currently, not all the CGtests pass, but there is a list on the Trac wiki
  56	for Tock of all the tests currently expected to pass/fail.
  57	\item Automatic test harness. Currently very simplistic, but essentially a couple of helper functions in the
  58	\lstinline|TestHarness| module allow you to easily provide an external file of occam code tests and to specify
  59	whether this code should provoke an error from the compiler (at least, everything before the final
  60	code-generation step).
  61
  62	\subsection{HUnit}
  63
  64	For most of your tests, HUnit will be the most appropriate. The main HUnit data type is as follows:
  49	65
  50	66	\begin{lstlisting}
  …	…
  65	81	assertEqual :: (Eq a, Show a) => String -> a -> a -> Assertion
  66	82	\end{lstlisting}
  83	(追記) (追記ここまで)
  84	(追記) \subsubsection{Labelling Tests} (追記ここまで)
  67	85
  68	86	The first argument is the label. I usually use this as a subsitute for a test name; you'll commonly see
  …	…
  88	106	\end{enumerate}
  89	107
  108	(追記) \subsubsection{Other items} (追記ここまで)
  109	(追記) (追記ここまで)
  110	(追記) Furthermore, the next two arguments of the \lstinline|assertEqual| function are the expected test output (追記ここまで)
  111	(追記) and the actual test output in that order. So you might write something like: (追記ここまで)
  112	(追記) (追記ここまで)
  113	(追記) \begin{lstlisting} (追記ここまで)
  114	(追記) assertEqual "concatString Test 0" "foobar" (concatString "foo" "bar") (追記ここまで)
  115	(追記) \end{lstlisting} (追記ここまで)
  116	(追記) (追記ここまで)
  117	(追記) This is of type \lstinline|Assertion|; prefix it with \lstinline|TestCase $| to make it a \lstinline|Test|. (追記ここまで)
  118	(追記) (追記ここまで)
  119	(追記) There are many helper functions related to building up input for tests (particularly AST fragments) (追記ここまで)
  120	(追記) and for performing customised assertions (especially for testing passes in the \lstinline|PassM| monad) (追記ここまで)
  121	(追記) in the \lstinline|TestUtil| module that you should always look there to see if it has a helper function (追記ここまで)
  122	(追記) that would be useful to you. Similarly, if you think any of your own test helper functions could be (追記ここまで)
  123	(追記) useful in other places, add them to the \lstinline|TestUtil| module. (追記ここまで)
  124	(追記) (追記ここまで)
  125	(追記) \subsection{Wiring In The Tests} (追記ここまで)
  126	(追記) (追記ここまで)
  127	(追記) If you are adding to an existing portion of Tock, then you should add your tests alongside the existing (追記ここまで)
  128	(追記) tests. Most of Tock is tested; if you add to a bit that is not tested then please consider writing (追記ここまで)
  129	(追記) tests for the old code too. (追記ここまで)
  130	(追記) (追記ここまで)
  131	(追記) When writing a new chunk of functionality you will want to create a new module for the tests. The general (追記ここまで)
  132	(追記) pattern is to put the tests for module \lstinline|Foo| into module \lstinline|FooTest|. You should (追記ここまで)
  133	(追記) then import the module you are testing, any other appropriate modules, and \lstinline|Test.HUnit|. (追記ここまで)
  134	(追記) (追記ここまで)
  135	(追記) By convention, you should provide one (and only one) of the following functions in your test module: (追記ここまで)
  136	(追記) (追記ここまで)
  137	(追記) \begin{enumerate} (追記ここまで)
  138	(追記) \item \lstinline|tests :: Test| (remember that a \lstinline|Test| can be a \lstinline|TestList|) (追記ここまで)
  139	(追記) \item \lstinline|qcTests :: (Test, [QuickCheckTest])| (追記ここまで)
  140	(追記) \item \lstinline|ioqcTests :: IO (Test, [QuickCheckTest])| (追記ここまで)
  141	(追記) \end{enumerate} (追記ここまで)
  142	(追記) (追記ここまで)
  143	(追記) You should provide an export list for your module that contains only this function. This is very useful, (追記ここまで)
  144	(追記) as it means that any tests you write in your test module but forget to call in its exported (追記ここまで)
  145	(追記) \lstinline|tests| function will be flagged up by the compiler as unused. (追記ここまで)
  146	(追記) (追記ここまで)
  147	(追記) Then add your new test module to the list in the \lstinline|TestMain| module. Add the appropriate import (追記ここまで)
  148	(追記) declaration, and look at the very foot of the file for the \lstinline|tests| list. Wrap your function (追記ここまで)
  149	(追記) according to its type, following the pattern of the other functions there. That is, you may need to (追記ここまで)
  150	(追記) add the \lstinline|noqc| or \lstinline|return| wrapper functions. (追記ここまで)
  151	(追記) of the file for the \lstinline|tests| function, and (追記ここまで)
  152	(追記) (追記ここまで)
  153	(追記) (追記ここまで)
  90	154	\section{Comment Your Code}
  91	155

Note: See TracChangeset for help on using the changeset viewer.