poolparty 0.2.69 → 0.2.84

data/lib/erlang/messenger/lib/eunit/.svn/text-base/NOTES.svn-base

@@ -1,276 +0,0 @@
-
-EUnit Developer notebook
-========================
-
-Concepts and features
----------------------
-
- - Separation of tests and test runners (different ways of reporting)
-
-   * Tests are represented by data structures
-   * Traversal and execution are separated
-   * TODO: Cannot enumerate all tests in advance for really large sets
-
- - Test engine as a producer/iterator: run next, step back, repeat...
-
-   * Iterators working (reverse/single stepping currently not used)
-   * TODO: Need to be able to stop after N failures
-
- - Test module - a container (as in 'eunit:run(M)'); automatic test collection
-
-   * Works; a module name can be used to represent its set of tests.
-
- - Single tests (exported nullary functions, to be called directly)
-
-   * Works; has drawbacks (no comments, context, or order, many
-     functions)
-
- - Abstraction of tests, for reuse
-
-   * Tests are just nullary funs; this is both simple and powerful
-   * You can use 'fun name/arity' or 'fun module:name/arity' for sharing code
-   * Generator functions are used to create specialized test funs
-
- - Executing a test by calling directly should have observable
-   failure/success, and tests should not in themselves output test
-   results to console or otherwise
-
-   * Tests succeed by returning properly (any return value)
-   * Tests fail by throwing an exception (any exception)
-
- - It should be possible to run single tests without eunit runtime support
-
-   * Just apply a test function to an empty argument list and see if it
-     throws an exception or not
-   * More complex test representations (grouping, setup/teardown etc.)
-     need eunit support functions
-
- - It should be possible to write tests without requiring eunit headers
-
-   * Using plain tuples, funs, atoms, and lists to represent tests; not
-     more difficult, just less convenient.
-
- - Tests are identified by: module/sourcefile, test function name, and
-   line number (if available)
-
-   * This is also used in listings of test sets
-   * Funs have useful metadata, which allows most of the identifying
-     info to be extracted automatically
-
- - Test functions must be identified as either directly callable or as
-   returning one or more test representations (the latter is referred to
-   as a "generator"). We cannot just try to call any function and check
-   the result - it would not be possible to _collect_ tests without
-   accidentally _executing_ tests in that case. So, the simplest form of
-   test generator function should return a nullary fun. This can be
-   tested directly and easily by a user.
-
-   * Using a '_test_' suffix (as opposed to a '_test' suffix) for test
-     generator functions (that return test *representations*) is a good
-     idea, since it makes it easy to accomodate both styles of writing
-     tests, does not break existing code, allows both types of functions
-     to be automatically detected, and makes it easy to write wrapper
-     functions. The underscore just before the opening parenthesis makes
-     it more visible than most other variants.
-
- - Conditional compilation of test code
-
-   * Defining the NOTEST macro is used to disable testing code; this is
-     used by all the eunit header files.
-   * Testing can be disabled by default by including eunit_off.hrl
-     instead of eunit.hrl, or before any other eunit header file; then,
-     defining the TEST macro externally will enable the testing code.
-     The same effect is achieved by defining NOTEST before including
-     eunit.hrl or any other eunit header file, but using eunit_off.hrl
-     is always independent of the actual macro name used for control.
-
- - Exporting test functions manually is annoying and easy to forget
- - Decorating a normal module with common eunit entry functions
-
-   * Including eunit.hrl inserts a parse transform (unless NOTEST or
-     EUNIT_NOAUTO is defined) which automatically exports functions
-     identified as test functions with the proper suffixes and arity,
-     and adds a test/0 function to the module (unless it exists).
-
- - Label of a single test
-
-   * {"...", Test}, also works for groups.
-
- - Context of a single test; set up and tear down of context; multiple
-   tests within same context (single set up/tear down)
-
-   * {setup, Setup, Teardown, Generator}
-   * {setup, Setup, Generator} works as a simple let-binding
-
- - Multiple tests using same context (individual set up/tear down)
-
-   * {foreach, Setup, Teardown, [Generator]}
-     {foreach1, Setup, Teardown, [{Arg, Generator}]}
-
- - Aggregation of tests in an order-dependent sequence; aggregation of
-   tests in explicitly parallel sets
-
-   * {inorder, T} | {inparallel, T}
-
- - Aggregation of tests in unspecified-order sets
-
-   * Deep lists represent generic test sets
-
- - Test suites: label of a test suite, composition of test suites
-
-   * Deep lists and {"label", DeepList} work fine for this purpose
-
- - Defining test suites without modifying code or creating new modules.
-
-   * This does not create new tests - just select specific modules or
-     functions. If there is need for expressiveness beyond a simple list
-     of constant terms (no funs), it should be put in a module. Hence, a
-     facility for "consulting" files should be sufficient.
-   * Works (simply writing "filename" or {file, "filename"}).
-
- - Extra header files for better macro namespace separation (eunit_...)
-
-   * Seems to be overkill - the leading underscore in the normal macros
-     lessens the need for such double definitions
-
- - Running tests in parallel
-
-   * Works (also running N tests at a time)
-   * TODO: Restructure to start new job as soon as slot is available
-
- - Running a test or set of tests in a new process (like setup/teardown)
-
-   * Works
-
- - Running tests on a separate (existing) node
-
-   * Implemented as {spawn, Node, Tests}: assuming a specific node
-     exists, run a set of tests on that node, rather than locally, the
-     main idea being that a number of test sets could be run in parallel
-     on separate machines (and maybe none are run locally)
-
- - Running OS commands, testing output and result values
-
-   * Works; output is normalized to LF only for linebreaks on all platforms
-   * TODO: Better Windows support (not much tested)
-   * TODO: Is it possible to capture stderr separately somehow?
-
- - Starting one or more additional nodes to run tests or suites on
-
-   * {node, foo@bar.baz, Instantiator}
-   * {node, foo, Instantiator}
-
- - Whole-application testing (using .app files?)
-
-   * {application, AppName}
-   * {file, AppFile}
-
- - Identification of tests within a test set (e.g., which succeeded,
-   which failed, repeating selected tests or groups of tests, etc.)
-
-   * The numbering scheme in listings take care of this point
-
- - Running EUnit from command line, as a standalone tool
-
-   * TODO: Command line interface similar to that of edoc
-
- - Open source (licensed under the GNU Lesser General Public Licence)
-
-   * Header files can be used without tainting, according to LGPL
-
- - Marking tests as known failures, for handling known bugs
-
-   * TODO: Known-failure is necessary to avoid writing "inverted-logic" tests
-   * TODO: Is it possible to handle known timout/setup failures?
-
- - Diagnostic tests which never fail, but may cause warnings
-
-Assorted notes which may or may not be useful, e.g. for documentation
----------------------------------------------------------------------
-
-Tests for exported functions of a module should preferably be in a
-separate module. This is good in many ways, but mainly boils down to
-that modifying test code should not have to imply modifying source code,
-and vice versa. At the same time, it should be possible for a module to
-export test functions for private functions, and to have these tests
-conditionally compiled (use -ifdef(EUNIT) or -ifdef(TEST) for this).
-
-Pyunit uses 'failIf' and 'failUnless' as standard test names, and
-'assert' as a synonym for 'failUnless'. I have settled on 'assert' and
-'assertNot' as the standard names. Maybe I'll add 'failUnless' and
-'failIf' as synonyms, if users ask for it.
-
-Junit/Pyunit get a lot of context embedding for free due to the object
-oriented languages (using class members and inheritance); in Erlang,
-context must be passed to tests as arguments or through local variable
-bindings if there are multiple tests within a function clause. This is
-particularly important for reuse of tests with small variations. To be
-able to instantiate the environment of a set of tests when executing a
-setup, the setup must be a function which returns the test set and the
-cleanup function.
-
-A list of tests represents an order-independent set. Usually, the tests
-will be run in order, but it is not required and tests may also be
-executed in parallel if they are included in an 'inparallel'-context.
-Labeling a set of tests does not change its meaning in any way.
-
-Wrapping a set of tests in a 'setup' implies that the setup is executed,
-then _all_ the tests (those returned by the generator fun) are executed,
-and finally the cleanup is executed regardless of whether any tests
-failed or not. If the setup itself failed, the whole test set _and_ the
-cleanup is skipped (there is no setup-result that can be passed to the
-cleanup).
-
-Wrapping a (deep) list of generators in a 'foreach' is equivalent to
-wrapping each individual generator in the list in a corresponding
-'setup', regardless of nesting depth. E.g., foreach(a, [foreach(b, [t1,
-t2]), foreach(c, [t3, t4])]) is equivalent to [setup(a, setup(b, t1)),
-setup(a, setup(b, t2)), setup(a, setup(c, t3)), setup(a, setup(c, t4))].
-Note that 'foreach' does not distribute over 'setup', since the nesting
-level of 'setup' must be preserved.
-
-While a plain 'foreach' can be done over any set of generators, a
-'foreach1' requires that there is a pairing of argument+generator for
-each element.
-
-See the file eunit_data.erl for a description of test representations.
-
-Lists of tests/generators/arg-generator-pairs can all be deep, but every
-sublist must be a proper list, i.e., nil-terminated.
-
-Test Set Traversal Operations (traversal only - no execution here):
-
-     Init: create iterator from test representation.
-     Next: the most common operation - get the next test or group
-     Previous: step back to the previous operation (in the group)
-     Enter: enter a group, executing any side effects
-     Browse: enter a group without triggering side effects
-     Up: leave the current group
-
-Problem: cannot browse a 'setup'-group unless you are able to instantiate
-the generator fun, and to do that you either need the actual result from
-the 'setup' fun, or you need to know if the generator fun expects an
-argument matching a certain pattern, such as a 3-tuple. You could then
-pass dummy values such as 'undefined' for the components, since they
-will not be used unless you try to run one of the instantiated tests or
-a setup fun of a subgroup.
-
-If there was never a fun that returned a list of tests, but only funs
-around single tests, it would be simple - just don't apply any funs
-while traversing. But then it would be necessary to wrap each test
-within a 'setup' in its own generator fun, which would be a pain, and it
-would not be possible to nest 'setup' groups in an easy way (variables
-bound in the outer group would have to be explicitly passed to the
-generator funs in the inner group, using manual closure conversion). This
-is simply not tolerable. So, dummy value instantiation is the only way
-to go, if it should be possible at all to browse test groups without
-executing setup/cleanup funs.
-
-Solution: a 'browser' function that tries to pass variants of dummy
-values to a fun until it either succeeds or fails with some other error
-than 'fun_clause'. This has been implemented and is the basis of the
-test listing function.
-
-When a setup-group is being browsed, its tests cannot be executed (since
-they are instantiated with dummy values), and its subgroups can only be
-further Browsed, not Entered, for the same reason.

data/lib/erlang/messenger/lib/eunit/.svn/text-base/README.svn-base

@@ -1,3 +0,0 @@
-EUnit 2.0 Beta release
-
-See the doc/ subdirectory for documentation in HTML.

data/lib/erlang/messenger/lib/eunit/.svn/text-base/sys.config.svn-base

@@ -1,9 +0,0 @@
-[
- {kernel,
-  [{error_logger, 
-    {file, "priv/eunit.log"}}]},
- {sasl,
-  [{sasl_error_logger, false},
-   {error_logger_mf_dir, "."},
-   {error_logger_mf_maxfiles, 20},
-   {error_logger_mf_maxbytes, 1000000}]}].

data/lib/erlang/messenger/lib/eunit/.svn/text-base/vsn.mk.svn-base

@@ -1 +0,0 @@
-EUNIT_VSN = 2.0 beta 1

data/lib/erlang/messenger/lib/eunit/doc/.svn/all-wcprops

@@ -1,59 +0,0 @@
-K 25
-svn:wc:ra_dav:version-url
-V 38
-/contribs/!svn/ver/263/trunk/eunit/doc
-END
-overview.edoc
-K 25
-svn:wc:ra_dav:version-url
-V 52
-/contribs/!svn/ver/263/trunk/eunit/doc/overview.edoc
-END
-stylesheet.css
-K 25
-svn:wc:ra_dav:version-url
-V 53
-/contribs/!svn/ver/172/trunk/eunit/doc/stylesheet.css
-END
-edoc-info
-K 25
-svn:wc:ra_dav:version-url
-V 48
-/contribs/!svn/ver/172/trunk/eunit/doc/edoc-info
-END
-modules-frame.html
-K 25
-svn:wc:ra_dav:version-url
-V 57
-/contribs/!svn/ver/219/trunk/eunit/doc/modules-frame.html
-END
-overview-summary.html
-K 25
-svn:wc:ra_dav:version-url
-V 60
-/contribs/!svn/ver/263/trunk/eunit/doc/overview-summary.html
-END
-eunit.html
-K 25
-svn:wc:ra_dav:version-url
-V 49
-/contribs/!svn/ver/263/trunk/eunit/doc/eunit.html
-END
-packages-frame.html
-K 25
-svn:wc:ra_dav:version-url
-V 58
-/contribs/!svn/ver/219/trunk/eunit/doc/packages-frame.html
-END
-index.html
-K 25
-svn:wc:ra_dav:version-url
-V 49
-/contribs/!svn/ver/219/trunk/eunit/doc/index.html
-END
-erlang.png
-K 25
-svn:wc:ra_dav:version-url
-V 49
-/contribs/!svn/ver/219/trunk/eunit/doc/erlang.png
-END

data/lib/erlang/messenger/lib/eunit/doc/.svn/entries

@@ -1,142 +0,0 @@
-8
-
-dir
-263
-http://svn.process-one.net/contribs/trunk/eunit/doc
-http://svn.process-one.net/contribs
-
-
-
-2008-10-12T12:17:56.811879Z
-263
-rcarlsson
-
-
-svn:special svn:externals svn:needs-lock
-
-
-
-
-
-
-
-
-
-
-
-5c723cce-c907-0410-9aa2-ab8348fff7a4
-
-overview.edoc
-file
-
-
-
-
-2008-10-18T23:25:35.000000Z
-af4447cd25c26312306f2f70586aa6fb
-2008-10-12T12:17:56.811879Z
-263
-rcarlsson
-
-stylesheet.css
-file
-
-
-
-
-2008-10-18T23:25:35.000000Z
-6e11b8ef1d68117868228d9fd1e4fce9
-2007-03-22T19:20:34.421238Z
-172
-rcarlsson
-
-edoc-info
-file
-
-
-
-
-2008-10-18T23:25:35.000000Z
-5ae38b5d072e0202af1bfbaf6aebd1ed
-2007-03-22T19:20:34.421238Z
-172
-rcarlsson
-
-modules-frame.html
-file
-
-
-
-
-2008-10-18T23:25:35.000000Z
-c9d803b4b7cd0380b1f4a58786252366
-2007-05-10T11:49:35.930693Z
-219
-rcarlsson
-has-props
-
-overview-summary.html
-file
-
-
-
-
-2008-10-18T23:25:35.000000Z
-849e34a030ef1d2176958f6810feec4f
-2008-10-12T12:17:56.811879Z
-263
-rcarlsson
-has-props
-
-eunit.html
-file
-
-
-
-
-2008-10-18T23:25:35.000000Z
-7724288cbff17b29387d6f830d5a856a
-2008-10-12T12:17:56.811879Z
-263
-rcarlsson
-has-props
-
-packages-frame.html
-file
-
-
-
-
-2008-10-18T23:25:35.000000Z
-a720dd0c1a9a393f3ab4208082c2357b
-2007-05-10T11:49:35.930693Z
-219
-rcarlsson
-has-props
-
-index.html
-file
-
-
-
-
-2008-10-18T23:25:35.000000Z
-71189e0120cccc4749a4960b5dae52a2
-2007-05-10T11:49:35.930693Z
-219
-rcarlsson
-has-props
-
-erlang.png
-file
-
-
-
-
-2008-10-18T23:25:35.000000Z
-f6077f849b23033f1533877a2f236bd6
-2007-05-10T11:49:35.930693Z
-219
-rcarlsson
-has-props
-

data/lib/erlang/messenger/lib/eunit/doc/.svn/format

@@ -1 +0,0 @@
-8

data/lib/erlang/messenger/lib/eunit/doc/.svn/prop-base/erlang.png.svn-base

@@ -1,5 +0,0 @@
-K 13
-svn:mime-type
-V 9
-image/png
-END

data/lib/erlang/messenger/lib/eunit/doc/.svn/prop-base/eunit.html.svn-base

@@ -1,5 +0,0 @@
-K 13
-svn:mime-type
-V 9
-text/html
-END

data/lib/erlang/messenger/lib/eunit/doc/.svn/prop-base/index.html.svn-base

@@ -1,5 +0,0 @@
-K 13
-svn:mime-type
-V 9
-text/html
-END

data/lib/erlang/messenger/lib/eunit/doc/.svn/prop-base/modules-frame.html.svn-base

@@ -1,5 +0,0 @@
-K 13
-svn:mime-type
-V 9
-text/html
-END

data/lib/erlang/messenger/lib/eunit/doc/.svn/prop-base/overview-summary.html.svn-base

@@ -1,5 +0,0 @@
-K 13
-svn:mime-type
-V 9
-text/html
-END

data/lib/erlang/messenger/lib/eunit/doc/.svn/prop-base/packages-frame.html.svn-base

@@ -1,5 +0,0 @@
-K 13
-svn:mime-type
-V 9
-text/html
-END

data/lib/erlang/messenger/lib/eunit/doc/.svn/text-base/edoc-info.svn-base

@@ -1,3 +0,0 @@
-{application,eunit}.
-{packages,[]}.
-{modules,[eunit]}.