Every repository with this icon (
Every repository with this icon (
Quick Start
Step 1: Get/Install Snap
Either grab the latest source from GIT or from the download tab. Please note the GIT version will always be bleeding edge, and will receive often/more updates than the Downloads tab. However, the Downloads tab is recommended for stability.
Place Snap wherever you want, and run a self test:
- if you have php in an obvious location (path, /usr/bin, /usr/local/bin, /opt/local/bin), run the command
./snaptest.sh ./from inside the snaptest directory. - if php is not in an obvious location, you can run
./snaptest.sh ./ --php<path>where<path>indicates the location of your php binary. - if shell scripting for whatever reason isn’t working, you can also use the PHP binary directly by calling
<php> snaptest.php --path=<php> ./where<php>is the location of your php binary.
When ran, you should see output like the following:
User@Host ~/snaptest> ./snaptest.sh ./
...............................................................................................
______________________________________________________________________
Total Cases: 37
Total Tests: 95
Total Pass: 95
Total Defects: 0
Total Failures: 0
If you don’t get any failures (marked with an F followed by information about the error, you’re ready to go!
Step 2: Make Your Own Test
By default, !SnapTest files end in .stest.php although this can be changed with a command line parameter (see CommandLineOptions). A default UnitTestClass contains the minimum code needed to run a test:
class Your_Class_Name extends Snap_UnitTestCase {
public function setUp() {}
public function tearDown() {}
/** stub, example test
public function testBooleanTrueIsTrue() {
return $this->assertTrue(true);
}
end stub **/
}
The class must extend Snap_UnitTestCase and therefore will implement Snap_RunnableTestInterface (providing a runTests() method). setUp and tearDown are used at the beginning and end of each unit test respectively (see TestScaffolding) to ensure the environment is consistent between tests.
Classes should be clear and descriptive of the scenario they are testing. For example, if you are testing class Foo under the condition where it owns a Bar that doesn’t connect, name your class Foo_Bar_Doesnt_Connect_Test{}
Methods that will be ran begin match the pattern ^test.+$. This means they begin with the word “test”, followed by the rest of the test’s name. It is good practice to write the test name in camel-case and make it readable. This will help with your testing output and for output methods like TAP.
| method name | ok? |
|---|---|
| testWorks() | bad – should be more clear, what works? |
| testInstantiatedClassIsAWidget() | good |
| testReturnsFalse() | bad – what returns false? |
| testExecuteReturnsFalse() | good |
Step 3: Run Your Test
You can now call snaptest.sh again, and point at your newly created test file:
User@Host ~/snaptest> ./snaptest.sh <path-to-your-file>.stest.php
.
______________________________________________________________________
Total Cases: 1
Total Tests: 1
Total Pass: 1
Total Defects: 0
Total Failures: 0






