• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
The Test Anything Protocol
 

The Test Anything Protocol

on

  • 2,767 views

The Test Anything Protocol or

The Test Anything Protocol or
Small Testing Tools Loosely Joined or
How to make large automated test suites less of a complete PITA.

Statistics

Views

Total Views
2,767
Views on SlideShare
2,765
Embed Views
2

Actions

Likes
1
Downloads
18
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • There are lots of different kinds of automated test you can write <br />
  • There are lots of tools for implementing different kinds of testing in the language of your choice <br />
  • The problem comes when you have multiple languages and testing models in the same system. <br />
  • Different languages, different testing models, different outputs, different inputs. <br />
  • Makes integrating different systems hard. <br />
  • Writing your own custom piece of automated testing is also a pain. <br />
  • And everybody does it differently. The cause of the earlier problem. <br />
  • TAP = Test Anything Protocol <br />
  • Simple model. A test producer streams out TAP that is read by a test consumer. <br />
  • So we can have different kinds of automated test framework all output TAP - and they can all be understood by a single consumer. <br />
  • ... and we can have different kinds of test consumer that do interesting things with the results of your tests. <br />
  • It&#x2019;s a good way of building systems. <br />
  • This is about the simplest possible example of TAP. <br />
  • This is the plan - it says we&#x2019;re running three tests. <br />
  • This indicates a passing test. <br />
  • This is a human-readable summary of the passing test <br />
  • Failing tests are just prefixed by &#x201C;not&#x201D;. <br />
  • TAP deals with more than just the simple case <br />
  • <br />
  • <br />
  • <br />
  • Some examples of how TAP can be used. <br />
  • Takes TAP output <br />
  • Shows you passing and failing tests <br />
  • Draws you pretty graphs over time (for certain definitions of &#x201C;pretty&#x201D;) <br />
  • Another example <br />
  • Massively distributed system for testing Perl modules from CPAN on multiple platforms, dependency variations, perl versions, etc. <br />
  • This is where you should go to find out more about TAP. <br />
  • Questions? Just drop me a line. <br />

The Test Anything Protocol The Test Anything Protocol Presentation Transcript

  • The Test Anything Protocol or Small Testing Tools Loosely Joined or How to make large automated test suites less of a complete PITA.
  • xUnit / declarative testing / load testing / procedural tests / record|replay / TDD / BDD / etc.
  • JUnit / SUnit / TestNG / Test::Builder / Test::Unit / jsUnit / PHPUnit / Cucumber / Selenium / Watir / RSpec / JSpec /
  • Problem: Using them together
  • Integrating automated test suites is a PITA
  • Everything is tightly coupled
  • Writing new test environments is a PITA
  • Everybody has to figure out how to produce, consume and report test results
  • TAP aims to help
  • Test Producer TAP Test Consumer
  • BDD xUnit Load Tests TAP TAP TAP Test Consumer
  • Test Producer TAP Continuous IDE Reporting Integration
  • Small Pieces Loosely Joined
  • 1..3 ok 1 - we can foo ok 2 - we can bar not ok 3 - we can ni
  • 1..3 ok 1 - we can foo ok 2 - we can bar not ok 3 - we can ni
  • 1..3 ok 1 - we can foo ok 2 - we can bar not ok 3 - we can ni
  • 1..3 ok 1 - we can foo ok 2 - we can bar not ok 3 - we can ni
  • 1..3 ok 1 - we can foo ok 2 - we can bar not ok 3 - we can ni
  • And there’s more… • Diagnostic output • TAP versions • TODO / SKIP tests • Nested TAP (new-ish) • Structured diagnostics (in dev, in PHPUnit) • Draft IETF Standard (WIP)
  • TAP Philosophy • Work on the TAP as a stream • The TAP producer should be pluggable • The TAP consumer should be pluggable • Gracefully handle future upgrades to TAP
  • Working well in the Perl world for years and years and years…
  • Not just Perl • PHPUnit (PHP) • PLUTO (Oracle PL/SQL) • TAPS (C#) • pgTAP (PostgreSQL) • libtap (C) • tap-functions (sh) • Test.Simple (JavaScript) • etap (Erlang) • PyTAP (Python) • arctap.arc (Arc) • Bacon (Ruby) • libtap++ (C++) • Forth/TAP (Forth) • JTap (Java)
  • Smolder
  • CPAN Testers
  • testanything.org
  • You should ask questions now :-) adrianh@quietstars.com twitter.com/adrianh quietstars.com