racket/collects/tests/framework
Eli Barzilay 699c40643d * Changed setup-plt to compile collections if they have an "info.ss"
file.  (That is, it does not require the file to have a `name'
  entry.)

* The name shown when setup works is the directory name, followed by
  the `name' field from the info file when specified.

* This means that many `name's are no longer needed, so I'm removing
  them.  To see if you need a `name' entry, consider that the name
  will be shown like this:
    ... foo (<your name here>)
  This means that if the name is the same as the directory name, then
  there is no point in having it.  I also removed cases where the name
  differed only in its capitalization for collections where the case
  is obvious.

* Also, for subcollections, the name should clarify the name of the
  subcollection in context.  For example "Acknowledgments" explains
  what scribbling/acks is, but there's no need to add the context name
  as in "Scribblings: Acknowledgments".

* There may also be a point in keeping names for other uses.  One such
  example was in games, where the name field was used in the PLT Games
  application.  (This was changed to default on the directory name, so
  it is no longer needed in most games.)  Another example is in planet
  packages.

svn: r8629
2008-02-12 10:33:01 +00:00
..
canvas.ss
debug.ss
exit.ss
frame.ss fixed up some of the old tests 2007-05-07 01:30:32 +00:00
framework-test set svn:eol-style and executable properties 2006-07-19 05:01:31 +00:00
framework-test-engine set svn:eol-style and executable properties 2006-07-19 05:01:31 +00:00
framework-test-engine.icns
framework-test-engine.ss 359.2, collects changes 2006-12-20 00:57:12 +00:00
group-test.ss fixed up some of the old tests 2007-05-07 01:30:32 +00:00
handler-test.ss
info.ss * Changed setup-plt to compile collections if they have an "info.ss" 2008-02-12 10:33:01 +00:00
keys.ss added local-like category to square bracketing magic 2007-07-10 16:13:09 +00:00
load.ss fixed up minor bugs in program and lots of little problems in the test suites 2007-05-08 01:02:40 +00:00
main.ss
mem.ss
panel.ss
pasteboard.ss
prefs.ss changed the strategy of the preferences library in the framework to use a different key at the file.ss level (and thus save the prefs on each call to preferences:set) 2006-12-07 22:32:31 +00:00
README cleanups in test suites 2006-07-19 04:34:48 +00:00
test-suite-utils.ss
text.ss cleanups in test suites 2006-07-19 04:34:48 +00:00
utils.ss

`(#|
		      Framework Test Suite Overview

Each tests will rely on the sucessfully completion of all of the ones
before it. In addition, all test suites rely on the sucessful
completion of the engine test suites and the mzscheme test suites.

All of these tests reside in PLTHOME/collects/tests/framework/

There will be a main mzscheme process which will start up a new mred
as necessary for the test suites. Since some tests actually require
mred to exit in order to pass, this governor is required. 

To run a test use:

   framework-test <test.ss> ...

where or <test.ss> is the name of one of the tests below.
(Note: uncomment the launcher entries in info.ss for this.)
Alternatively, pass no command-line arguments to run all of
the tests. (Under windows, the app will be named "Framework
Test"; see the mred-launcher-names documentation for how the
names change on the various platforms)

Some of the tests in this file are not yet present in the
testing directory. They are planned future expansions of
this test suite (and have been for some time....)

OS X: you will have to click on the newly started mred
processes in the doc while the test suite runs or it will
signal failures when there aren't any.

- load: |# load.ss #|

  | This tests that the advertised ways of loading the framework at
  | it's components all work.

- exit: |# exit.ss #|

  | This tests that exit:exit really exits and that the exit callbacks
  | are actually run.

- preferences: |# prefs.ss #|

  | This tests that preferences are saved and restored correctly, both
  | immediately and across reboots of mred.


- individual object tests:

  | These tests are simple object creation and basic operations.
  | Each test assumes that the others pass; this may yield strange
  | error messages when one fails.

  - frames: |# frame.ss #|
  - canvases: |# canvas.ss #|
  - texts: |# text.ss #|
  - pasteboards: |# pasteboard.ss #|

- keybindings: |# keys.ss #|

  | This tests the misc (non-scheme) keybindings

- group tests: |# group-test.ss #|

  | make sure that mred:the-frame-group records frames correctly.
  | fake user input expected.

- saving tests:

  | These tests will make sure that the usual checks against a user
  | losing their work are in place.

- interactive tests

  | these tests require intervention by people. Clicking and whatnot
  
  - panel:single |# panel.ss #|

  - garbage collection: |# mem.ss #|

    | These tests will create objects in various configurations and
    | make sure that they are garbage collected

	
|#)