From 2e76646998df0ca1b7d160329c0f3ac8cdda2fe0 Mon Sep 17 00:00:00 2001 From: Pjotr Prins Date: Sun, 20 Aug 2017 09:22:43 +0000 Subject: Move shunit2 into ./contrib and add catch-1.8.7 --- test/shunit2-2.0.3/src/docbook/functions.xml | 14 ---- test/shunit2-2.0.3/src/docbook/introduction.xml | 50 -------------- test/shunit2-2.0.3/src/docbook/quickstart.xml | 86 ------------------------- test/shunit2-2.0.3/src/docbook/shunit2.xml | 85 ------------------------ 4 files changed, 235 deletions(-) delete mode 100644 test/shunit2-2.0.3/src/docbook/functions.xml delete mode 100644 test/shunit2-2.0.3/src/docbook/introduction.xml delete mode 100644 test/shunit2-2.0.3/src/docbook/quickstart.xml delete mode 100644 test/shunit2-2.0.3/src/docbook/shunit2.xml (limited to 'test/shunit2-2.0.3/src/docbook') diff --git a/test/shunit2-2.0.3/src/docbook/functions.xml b/test/shunit2-2.0.3/src/docbook/functions.xml deleted file mode 100644 index c960e55..0000000 --- a/test/shunit2-2.0.3/src/docbook/functions.xml +++ /dev/null @@ -1,14 +0,0 @@ - - - - - - - Functions - This XML file is a placeholder. It is meant to be overwritten with the dynamically generated XML document that is extracted from the source code. - diff --git a/test/shunit2-2.0.3/src/docbook/introduction.xml b/test/shunit2-2.0.3/src/docbook/introduction.xml deleted file mode 100644 index d71b091..0000000 --- a/test/shunit2-2.0.3/src/docbook/introduction.xml +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - - - Introduction - shUnit2 is a unit test framework for Bourne based shell scripts, and it is designed to work in a similar manner to JUnit, PyUnit, etc. - - shUnit2 was originally developed to provide a consistent testing solution for log4sh, a shell based logging framework similar to log4j. During the development of that product, the problem of having things work just fine under one shell (/bin/bash on Linux to be specific), and then not working under another shell (/bin/sh on Solaris), kept coming up. Although there were several simple tests ran, they were not adaquate and did not catch very many corner cases. The decision was finally made to write a proper unit test framework after after multiple brown-bag releases were made. - -
Tested Operating Systems - - Cygwin - FreeBSD (user supported) - Linux (Gentoo, Ubuntu) - Mac OS X - Solaris 8, 9, 10 - -
- -
Tested Shells - - Bourne Shell (sh) - BASH - GNU Bourne Again SHell (bash) - DASH (dash) - Korn Shell (ksh) - pdksh - Public Domain Korn Shell (pdksh) - -
- - See the appropriate Release Notes (doc/RELEASE_NOTES-X.X.X.txt) for this release for the actual versions tested. - - -
Credits / Contributors - A list of contributors to shUnit2 can be found in the source archive as doc/contributors.txt. I want to personally thank all those who have contributed to make this a better tool. -
- - -
Feedback - Feedback is most certainly welcome for this document. Send your additions, comments and criticisms to the following email address: &myEmail;. -
- - diff --git a/test/shunit2-2.0.3/src/docbook/quickstart.xml b/test/shunit2-2.0.3/src/docbook/quickstart.xml deleted file mode 100644 index d009cb6..0000000 --- a/test/shunit2-2.0.3/src/docbook/quickstart.xml +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - Quickstart - - This chapter will give a very quick start to running unit tests with shUnit2. More information is located in other chapters. - - Here is a quick sample script to show how easy it is to write a unit test in shell. It expects that you have a copy of &shunit2; in the same directory as the script. - - - - - - Running the unit test should give results similar to the following. - - - - - - Wohoo! You've just run your first successful unit test. So, what just happened? Quite a bit really, and it all happened simply by sourcing the &shunit2; script. The basic functionality for the script above goes like this. - - When shUnit2 is sourced, it first looks to see if a suite() function has been declared. If it exists, it is called as it is expected to contain a list of tests to be executed. If it doesn't exist (and it doesn't in the above example), shUnit2 will look on its own for any functions that start with the string test, and adds those to an internal list of tests to execute. Once a list of test functions to be run has been determined, shunit2 will go to work. - - Before any tests are executed, shUnit2 again looks for a function, this time one named oneTimeSetUp(). If it exists, it will be run. This function is normally used to setup the environment for all tests to be run. Things like creating directories for output or setting environment variables are good to place here. Just so you know, you can also declare a corresponding function named oneTimeTearDown() function that does the same thing, but once all the tests have been completed. It is good for removing temporary directories, etc. - - shUnit2 is now ready to run tests. Before doing so though, it again looks for another function that might be declared, one named setUp(). If the function exists, it will be run before each test. It is good for resetting the environment so that each test starts with a clean slate. At this stage, the first test is finally run. The success of the test is recorded for a report that will be generated later. After the test is run, shUnit2 looks for a final function that might be declared, one named tearDown(). If it exists, it will be run after each test. It is a good place for cleaning up after each test, maybe doing things like removing files that were created, or removing directories. This set of steps, setUp() > test() > tearDown(), is repeated for all of the available tests. - - Once all the work is done, shUnit2 will generate the nice report you saw above. A summary of all the successes and failures will be given so that you know how well your code is doing. - - We should now try adding a test that fails. Change your unit test to look like this. - - - - - - So, what did you get? I guess it told you that this isn't 1999. Bummer, eh? Hopefully, you noticed a couple of things that were different about the second test. First, we added an optional message that the user will see if the assert fails. Second, we did comparisons of strings instead of integers as in the first test. It doesn't matter whether you are testing for equality of strings or integers. Both work equally well with shUnit2. - - Hopefully, this is enough to get you started with unit testing. If you want a ton more examples, take a look at the tests provided with log4sh. Examples of much more advanced usage can be seen there. shUnit2 was after all written to help with the unit testing problems that log4sh had. - diff --git a/test/shunit2-2.0.3/src/docbook/shunit2.xml b/test/shunit2-2.0.3/src/docbook/shunit2.xml deleted file mode 100644 index 25b3fed..0000000 --- a/test/shunit2-2.0.3/src/docbook/shunit2.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - - - - - - shunit2"> -]> - -shUnit2 - - shUnit2 version 2.0.3 - - - KateWard - -
- &myEmail; -
- - - - - - &isoDate; - - - - - - - 2.0.3 - 2007-07-12 - Kate Ward <&myEmail;> - - - - 2.0.2 - 2007-04-22 - Kate Ward <&myEmail;> - - - - 2.0.1 - 2007-02-21 - Kate Ward <&myEmail;> - - - - 2.0.0 - 2007-02-20 - Kate Ward <&myEmail;> - - - - - - shUnit2 is a unit test framework for Bourne based shell scripts, and it is designed to work in a similar manner to JUnit, PyUnit, etc. - - - - &introduction; - &quickstart; - &functions; - -- cgit v1.2.3