SoftwareTesting

Revision as of 06:52, 7 August 2006 by Davel (talk | contribs) (→‎Tools)

In The Ongoing Revolution in Software Testing (pdf), Cem Kaner defines testing as

[...] a technical investigation of a product, done to expose quality-related information.

This page is a starting point to find, learn about, and track technical investigations of the Mozilla codebase.

Please note: this catalog is not limited to investigations done by members of the Mozilla qa team and community.

Projects

Testing in General

Dave Liebreich is interested in creating running code to test the mozilla codebase. Not just end-to-end automated tests, but unit tests, module tests, test harnesses, test reporting infrastructure, and anything else that lowers the barrier to creating new code that gives someone feedback.

Dave is also interested in extending and improving the existing testing process. The information received from community testing efforts can be excellent and invaluable; Dave is looking for ways in which existing volunteers can improve their testing skill and skilled testers can join the effort.

Dave needs help. The codebase is huge. The community is huge. The task is huge.

Black-Box Testing

Software Update Testing

Project Ideas

  • Defining a common invocation mechanism for tests, with example code
  • Defining a common reporting format for tests
    • perl has TAP, xUnit has textrunner (. vs F)
  • fixture-based frameworks for test development
    • hosting of Fit/Fitnesse to run tests against a browser instance
    • tinderbox-based tests

Areas/concepts to investigate

  • xulUnit
  • jsUnit
    • xforms tests written using jsUnit
  • FireWatir
  • jUnit/FIT + javaxpcom
  • pyUnit/pyFIT + pyxpcom
  • webdav extension test harness (precursor to some calendar tests)
  • jsDriver.pl
    • what can we use/re-use
  • SoftwareTesting:2006-06-26 Brainstorm

Wishlist for xpcshell test harness

  • Unbuffered stdout, to get a useful log file even when the test hangs
  • Ability to run just a single test (with output to stdout rather than the logfile)
    • In particular, ability to run a single test in a debugger
    • Maybe as make check TEST=test_authentication.js, or as ./testone.sh test_authentication.js
  • Ability to mark tests as XFAIL when they are known to fail at the moment
  • non-fatal do_check_* (as new functions) to be able to see all the test failures, not just the first one
  • print log file on stdout for failed tests, especially useful when tinderbox runs the tests and one fails

Tools

People