docs/manual.txt

   1 = FiveAM Manual =
   2 Marco Baringer <mb@bese.it>
   3 Fall/Winter 2012
   4 :Author Initials: MB
   5 :toc:
   6 :icons:
   7 :numbered:
   8 :website: http://common-lisp.net/project/fiveam
   9 :stylesheet: fiveam.css
  10 :linkcss:
  11
  12 == Introduction ==
  13
  14 === The Super Brief Introduction ===
  15
  16 |================================
  17 | (xref:OP_DEF-TEST[`def-test`] `NAME` () &body `BODY`) | define tests
  18 | (xref:OP_IS[`is`] (`PREDICATE` `EXPECTED` `ACTUAL`)) | check that, according to `PREDICATE` our `ACTUAL` is the same as our `EXPECTED`
  19 | (xref:OP_IS[`is-true`] VALUE) | check that a value is non-NIL
  20 | (xref:OP_RUN![`run!`] TEST-NAME) | run one (or more) tests and print the results
  21 |================================
  22
  23 See the xref:API_REFERENCE[api] for details.
  24
  25 === An Ever So Slightly Longer Introduction ===
  26
  27 You use define some xref:TESTS[tests] (using
  28 xref:OP_DEF-TEST[`def-test`]), each of which consists of some
  29 xref:CHECKS[checks] (with xref:OP_IS[`is`] and friends) which can pass
  30 or fail:
  31
  32 --------------------------------
  33 (def-test a-test ()
  34   (is (= 4 (+ 2 2)))
  35   (is-false (= 5 (+ 2 2))))
  36 --------------------------------
  37
  38 you xref:RUNNING_TESTS[run] some tests (using xref:OP_RUN[run] and
  39 friends) and you look at the results (using using
  40 xref:OP_EXPLAIN[explain]); or you do both at once (using
  41 xref:OP_RUN-EPOINT-[run!]):
  42
  43 --------------------------------
  44 CL-USER> (run! 'a-test)
  45 ..
  46 Did 2 checks.
  47   Pass: 2 (100%)
  48   Skip: 0 (  0%)
  49   Fail: 0 (  0%)
  50 --------------------------------
  51
  52 Lather, rinse, repeat:
  53
  54 --------------------------------
  55 CL-USER> (run!)
  56 ..
  57 Did 2 checks.
  58   Pass: 2 (100%)
  59   Skip: 0 (  0%)
  60   Fail: 0 (  0%)
  61 --------------------------------
  62
  63 === The Real Introduction ===
  64
  65 FiveAM is a testing framework, this is a rather vague concept, so
  66 before talking about how to use FiveAM it's worth knowing what task(s)
  67 FiveAM was built to do and, in particular, which styles of testing
  68 FiveAM was designed to facilitate:
  69
  70 `test driven development`:: sometimes you know what you're trying to
  71   do (lucky you) and you can figure out what your code should do
  72   before you've written the code itself. The idea here is that you
  73   write a bunch of tests and when all these test pass your code is
  74   done.
  75
  76 `interactive testing`:: sometimes as you're writing code you'll see
  77   certain constraints that your code has to meet. For example you'll
  78   realize there's a specific border case your code, which you're
  79   probably not even done writing, has to deal with. In this work flow
  80   you'll write code and tests more or less simultaneously and by the
  81   time you're satisfied that your code does what it should you'll have
  82   a set of tests which prove that it does what you think it does.
  83
  84 `regression testing`:: sometimes you're pretty confident, just by
  85   looking at the code, that your program does what it should, but you
  86   want an automatic way to make sure that it continues to do what it
  87   does even if (when) you change other parts of the code.
  88
  89 [NOTE]
  90 There's also `beaviour driven development`. this works under
  91 the assumption that you can write tests in a natural-ish lanugage and
  92 they'll be easier to maintain than tests writen in code (have we
  93 learned nothing from cobol?). FiveAM does not, in its current
  94 implementation, support link:http://cukes.info/[cucumber] like
  95 behaviour driven development. patches welcome (they'll get laughed at
  96 at first, but they'll get applied, and then they'll get used, and then
  97 they'll be an essential part of fiveam itself...)
  98
  99 ==== Words ====
 100
 101 Since there are far many more testing frameworks than there are words
 102 for talking about testing frameworks, the same words end up meaning
 103 different things in different frameworks. Just to be clear, here are
 104 the words fiveam uses:
 105
 106 `check`:: a single expression which has an expected value.
 107
 108 `test`:: a set of checks which we want to always run together.
 109
 110 `suite`:: a group of tests we often want to run all at once.
 111
 112 [[TESTS]]
 113 == Tests ==
 114
 115 Tests are created with the xref:OP_DEF-TEST[`def-test`] macro and
 116 consist of:
 117
 118 A name::
 119
 120 Because everything deserves a name. Names in FiveAM are symbols (or
 121 anything that can be sensibly put in an `eql` hash table) and they are
 122 used both to select which test to run (as arguments to `run!` and
 123 family) and when reporting test failures.
 124
 125 A body::
 126
 127 Every test has a function which is the actual code that gets executed
 128 when the test is run. This code, whatever it is, will, bugs aside,
 129 xref:CHECKS[create a set of test result objects] (failures, successes
 130 and skips) and store these in a few dynamic variables (you don't need
 131 to worry about those).
 132 +
 133 The body is actually the only real part of the test, everything else
 134 is administrativia. Sometimes usefel administrativia, but none the
 135 less overhead.
 136
 137 A suite::
 138
 139 Generally speaking you'll have so many tests that you'll not want to
 140 run them all every single time you need to run one of them (automated
 141 regression testing is another use case). Tests can be grouped into
 142 suites, and suites can also be grouped into suites, and suites have
 143 names, so by specfying the name of a suite we only run those tests
 144 that are a part of that suite.
 145 +
 146 Unless otherwise specified tests add themselves to the xref:THE_CURRENT_SUITE[current suite].
 147
 148 There are two other properties, also set via parameters to
 149 xref:OP_DEF-TEST[`def-test`], which influence how the tests are
 150 run:
 151
 152 When to compile the test::
 153
 154 Often enough, when working with lisp macros especially, it's useful to
 155 delay compilation of the test's body until the test is run. A useful
 156 side effect of this delay is that the code will be recompiled every
 157 time its run, so if the macro definition has changed that will be
 158 picked up at the next run of the test. While this is the default mode
 159 of operation for FiveAM it can be turned off and tests will be
 160 compiled at the 'normal' time (when the enclosing def-test form is
 161 compiled).
 162
 163 Whether to run the test at all::
 164
 165 Sometimes, but far less often than the designer of FiveAM expected,
 166 it's useful to run a test only when some other test passes. The
 167 assumption being that if the lower level tests have failed there's no
 168 point in cluttering up the output by running the higher level tests as
 169 well.
 170 +
 171 YMMV. (i got really bad mileage out of this feature)
 172
 173 [[CHECKS]]
 174 == Checks ==
 175
 176 At the heart of every test is something which compares the result of
 177 some code to some expected value, in FiveAM these are called
 178 checks. All checks in FiveAM do something, exactly what depends on the
 179 check, and then either:
 180
 181 . generate a "this check passed" result
 182
 183 . generate a "this check failed" result and a corresponding failure
 184   description message.
 185
 186 . generate a "for some reason this check was skipped" result.
 187
 188 All checks take, as an optional argument, so called "reason format
 189 control arguments." Should the check fail (or be skipped) these
 190 arguments will be passed to format, via something like `(curry
 191 #'format nil)`, and the result will be used as the
 192 explanation/description of the failure.
 193
 194 When it comes to the actual check functions themeselves, there are
 195 three basic kinds:
 196
 197 . xref:CHECKING_RETURN_VALUES[those that take a value and compare it
 198 to another value]
 199
 200 . xref:CHECKING_CONTROL_FLOW[those that make sure the program's
 201 execution takes, or does not take, a certain path]
 202
 203 . xref:ARBITRARY_CHECK_RESULTS[those that just force a success or
 204 failure to be recorded].
 205
 206 [[CHECKING_RETURN_VALUES]]
 207 === Checking return values ===
 208
 209 xref:OP_IS[`IS`], xref:OP_IS-TRUE[`IS-TRUE`],
 210 xref:OP_IS[`IS-FALSE`] will take one form and compare its return
 211 value to some known value (the so called expected vaule) and report an
 212 error if these two are not equal.
 213
 214 --------------------------------
 215 ;; Pass if (+ 2 2) is = to 5
 216 (is (= 5 (+ 2 2)))
 217 ;; Pass if (zerop 0) is not-NIL
 218 (is-true (zerop 0))
 219 ;; Pass if (zerop 1) is NIL
 220 (is-false (zerop 1))
 221 --------------------------------
 222
 223 Often enough we want to test a set of expected values against a set of
 224 test values using the same operator. If, for example, we were
 225 implementing a string formatting functions, then `IS-EVERY` provides a
 226 concise way to line up N different inputs along with their expected
 227 outputs. For example, let's say we were testing `cl:+`, we could setup
 228 a list of tests like this:
 229
 230 --------------------------------
 231 (is-every #'= (5 (+ 2 2))
 232               (0 (+ -1 1))
 233               (-1 (+ -1 0))
 234               (1 (+ 0 1))
 235               (1 (+ 1 0)))
 236 --------------------------------
 237
 238 We'd do this instead of writing out 5 seperate `IS` or `IS-TRUE`
 239 checks.
 240
 241 [[CHECKING_CONTROL_FLOW]]
 242 === Checking control flow ===
 243
 244 xref:OP_SIGNALS[`SIGNALS`] and xref:OP_FINISHES[`FINISHES`] create
 245 pass/fail results depending on whether their body code did or did not
 246 terminat normally.
 247
 248 Both of these checks assume that there is a single block of code and
 249 it either runs to completion or it doesn't. Sometimes though the logic
 250 is more complex and you can't easily represent it as a single progn
 251 with a flag at the end. See xref:ARBITRARY_CHECK_RESULTS[below].
 252
 253 [[ARBITRARY_CHECK_RESULTS]]
 254 === Recording arbitrary test results ===
 255
 256 Very simply these three checks, xref:OP_PASS[`PASS`],
 257 xref:OP_FAIL[`FAIL`] and xref:OP_SKIP[`SKIP`] generate the specified
 258 result. They're intended to be used when what we're trying to test
 259 doesn't quite fit into any of the two preceding ways of working.
 260
 261 == Suites ==
 262
 263 Suites serve to group tests into managable (and runnable) chunks, they
 264 make it easy to have many tests defined, but only run those that
 265 pertain to what we're currently working on. Suites, like tests, have a
 266 name which can be used to retrieve the suite, and running a suite
 267 simply causes all of the suite's tests to be run, if the suite
 268 contains other suites, then those are run as well (and so on and so
 269 on).
 270
 271 There is one suite that's a little special (in so far as it always
 272 exists), the `T` suite. If you ignore suites completely, which is a
 273 good idea at first or for small(ish) code bases, you're actually
 274 putting all your tests into the `T` suite.
 275
 276 === Creating Suites ===
 277
 278 Suites are created in one of two ways: Either explicitly via the
 279 xref:OP_DEF-SUITE[`def-suite`] macro, or implicity via the
 280 xref:OP_DEF-SUITE-STAR-[`def-suite*`] and/or
 281 xref:OP_IN-SUITE-STAR-[`in-suite*`] macros:
 282
 283 Suites, very much like tests, have a name (which is globally unique)
 284 which can be used to retrieve the suite (so that you can run it), and,
 285 most of the time, suites are part of a suite (the exception being the
 286 special suite `T`, which is never a part of any suite).
 287
 288 For example these two forms will first define a suite called
 289 `:my-project`, then define a second suite called `:my-db-layer`, which
 290 is a sub suite of `:my-project` and set the current suite to
 291 `:my-db-layer`:
 292
 293 --------------------------------
 294 (def-suite :my-project)
 295
 296 (in-suite* :my-db-layer :in :my-project)
 297 --------------------------------
 298
 299 [[THE_CURRENT_SUITE]]
 300 === The Current Suite ===
 301
 302 FiveAM also has the concept of a current suite and everytime a test is
 303 created it adds itself to the current suite's set of tests. The
 304 `IN-SUITE` and `IN-SUITE*` macros, in a similar fashion to
 305 `IN-PACKAGE`, change the current suite.
 306
 307 Unless changed via `IN-SUITE` and `IN-SUITE*` the current suite is the
 308 `T` suite.
 309
 310 Having a default current suite allows developers to ignore suites
 311 completly and still have FiveAM's suite mechanism in place if they
 312 want to add suites in later.
 313
 314 [[RUNNING_SUITES]]
 315 === Running Suites ===
 316
 317 When a suite is run we do nothing more than run all the tests (and any
 318 other suites) in the named suite. And, on one level, that's it, suites
 319 allow you run a whole set of tests at once just by passing in the name
 320 of the suite.
 321
 322 [[SUITE_FIXTURES]]
 323 === Per-suite Fixtures ===
 324
 325 xref:FIXTURES[Fixtures] can also be associated with suite. Often
 326 enough when testing an external component, a database or a network
 327 server or something, we'll have multiple tests which all use a mock
 328 version of this component. It is often easier to associate the fixture
 329 with the suite directly than have to do this for every individual
 330 test. Associating a fixture to a suite doesn't change the suite at
 331 all, only when a test is then defined in that suite, then the fixture
 332 will be applied to the test's body (unless the test's own `def-test`
 333 form explicitly uses another fixture).
 334
 335 [[RUNNING_TESTS]]
 336 == Running Tests ==
 337
 338 The general interface is `run`, this takes a set of tests (or symbol
 339 that name tests or suites) and returns a list of test results (one
 340 element for each check that was executed). The output of `run` is,
 341 generally, passed to the `explain` function which, given an explainer
 342 object, produces some human readable text describing the test
 343 failures. The 99% of the time a human will be using 5am (as opposed to
 344 a continuous integration bot) they'll want to run the tests and
 345 immediately see the results with detailed failure info, this can be
 346 done in one step via: `run!` (see the first example).
 347
 348 If you want to run a specific test:
 349
 350 --------------------------------
 351 (run! TEST-NAME)
 352 --------------------------------
 353
 354 Where `TEST-NAME` is either a test object (as returned by `get-test`)
 355 or a symbol naming a single test or a test suite.
 356
 357 === Running Tests at Test Definition Time ===
 358
 359 Often enough, especially when fixing regression bugs, we'll always
 360 want to run a test right after having changed it. To facilitate this
 361 set the variable `*run-test-when-defined*` to T and after compiling a
 362 def-test form we'll call `run!` on the name of the test. For obvious
 363 reasons you have to set this variable manually after having loaded
 364 your test suite.
 365
 366 === Debugging failures and errors ===
 367
 368 `*debug-on-error*`::
 369
 370 Normally fiveam will simply capture unexpected errors, record them as
 371 failures, and move on to the next test (any following checks in the
 372 test body will not be run). However sometimes, well, all the time
 373 unless you're running an automated regression test, it's better to not
 374 capture the error but open up a debugger, set `*debug-on-error*` to
 375 `T` to get this effect.
 376
 377 `*debug-on-failure*`::
 378
 379 Normally FiveAM will simply record a check failure and move on to the
 380 next check, however it can be helpful to stop the check and use the
 381 debugger to see what the state of execution is at the time of the
 382 test's failure. Setting `*debug-on-failure*` to T will cause FiveAM to
 383 enter the debugger whenever a test check fails. Exactly what
 384 information is available is, obviously, implementation dependent.
 385
 386 [[VIEWING_TEST_RESULTS]]
 387 == Viewing test results ==
 388
 389 FiveAM provides two "explainers", these are classes which, given a set
 390 of results, produce some human readable/understandable
 391 output. Explainers are just normal CLOS classes (and can be easily
 392 subclassed) with one important method: `explain`.
 393
 394 The `run!` and `explain!` functions use the detailed-text-explainer,
 395 if you want another explainer you'll have to call `run` and `explain`
 396 yourself:
 397
 398 --------------------------------
 399 (explain (make-instance MY-EXPLAINER)
 400          (run THE-TEST)
 401          THE-STREAM)
 402 --------------------------------
 403
 404 == Random Testing (QuickCheck) ==
 405
 406 TODO.
 407
 408 Every FiveAM test can be a random test, just use the for-all macro.
 409
 410 == Fixtures ==
 411
 412 Fixtures are, much like macros, ways to hide common code so that the
 413 essential functionality we're trying to test is easier to see. Unlike
 414 normal macros fixtures are not allowed to inspect the source code of
 415 their arguments, all they can really do is wrap one form (or multiple
 416 forms in a progn) in something else.
 417
 418 [NOTE]
 419 Fixtures exist for the common case where we want to bind some
 420 variables to some mock (or test) values and run our test in this
 421 state. If anything more complicated than this is neccessary just use a
 422 normal macro.
 423
 424 Fixtures are defined via the `def-fixture` macro and used either with
 425 `with-fixture` directory or, more commonly, using the `:fixture`
 426 argument to `def-test` or `def-suite`. A common example of a fixture
 427 would be this:
 428
 429 --------------------------------
 430 (def-fixture mock-db ()
 431   (let ((*database* (make-instance 'mock-db))
 432         (*connection* (make-instance 'mock-connection)))
 433     (unwind-protect
 434         (&body) <1>
 435       (mock-close-connection *connection*))))
 436
 437 (with-fixture mock-db ()
 438   (is-true (database-p *database*)))
 439
 440 <1> This is a local macro named 5AM:&BODY (the user of def-fixture can
 441 not change this name)
 442
 443 --------------------------------
 444
 445 The body of the `def-fixture` has one local function (actually a local
 446 macro) called `&body` which will expand into whatever the body passed
 447 to `with-fixture` is. `def-fixture` also has an argument list, but
 448 there are two things to note: 1) in practice it's rarely used; 2)
 449 these are arguments will be bound to values (like defun) and not
 450 source code (like defmacro).
 451
 452 [[API_REFERENCE]]
 453 == API Reference ==
 454
 455 [[OP_DEF-TEST]]
 456 === DEF-TEST ===
 457
 458 ================================
 459 --------------------------------
 460 (def-test NAME (&key DEPENDS-ON SUITE FIXTURE COMPILE-AT PROFILE) &body BODY)
 461 --------------------------------
 462
 463 include::docstrings/OP_DEF-TEST.txt[]
 464 ================================
 465
 466 [[OP_DEF-SUITE]]
 467 === DEF-SUITE ===
 468
 469 ================================
 470 ----
 471 (def-suite NAME &key DESCRIPTION IN FIXTURE)
 472 ----
 473
 474 include::docstrings/OP_DEF-SUITE.txt[]
 475 ================================
 476
 477 [[OP_IN-SUITE]]
 478 [[OP_IN-SUITE-STAR-]]
 479 === IN-SUITE / IN-SUITE* ===
 480
 481 ================================
 482 ----
 483 (in-suite NAME)
 484 ----
 485
 486 include::docstrings/OP_IN-SUITE.txt[]
 487 ================================
 488
 489 ================================
 490 ----
 491 (in-suite* NAME &key IN)
 492 ----
 493
 494 include::docstrings/OP_IN-SUITE-STAR-.txt[]
 495 ================================
 496
 497 [[OP_IS]]
 498 === IS ===
 499
 500 ================================
 501 ----
 502 (is (PREDICATE EXPECTED ACTUAL) &rest REASON-ARGS)
 503
 504 (is (PREDICATE ACTUAL) &rest REASON-ARGS)
 505 ----
 506
 507 include::docstrings/OP_IS.txt[]
 508 ================================
 509
 510 [[OP_IS-TRUE]]
 511 [[OP_IS-FALSE]]
 512 === IS-TRUE / IS-FALSE / IS-EVERY ===
 513
 514 ================================
 515 ----
 516 (is-true CONDITION &rest reason)
 517 ----
 518
 519 include::docstrings/OP_IS-TRUE.txt[]
 520 ================================
 521
 522 ================================
 523 ----
 524 (is-false CONDITION &rest reason)
 525 ----
 526
 527 include::docstrings/OP_IS-FALSE.txt[]
 528 ================================
 529
 530 ////////////////////////////////
 531 //// the actual doc string of talks about functionality i don't want
 532 //// to publises (since it's just weird). se we use our own here
 533 ////////////////////////////////
 534 ================================
 535 ----
 536 (is-every predicate &rest (EXPECTED ACTUAL &rest REASON))
 537 ----
 538
 539 Designed for those cases where you have a large set of expected/actual
 540 pairs that must be compared using the same predicate function.
 541
 542 Expands into:
 543
 544 ----
 545 (progn
 546   (is (,PREDICATE ,EXPECTED ,ACTUAL) ,@REASON)
 547   ...
 548 ----
 549
 550 for each argument.
 551 ================================
 552
 553 [[OP_SIGNALS]]
 554 [[OP_FINISHES]]
 555 === SIGNALS / FINISHES ===
 556
 557 ================================
 558 ----
 559 (signals CONDITION &body body)
 560 ----
 561
 562 include::docstrings/OP_SIGNALS.txt[]
 563 ================================
 564
 565 ================================
 566 ----
 567 (finishes &body body)
 568 ----
 569
 570 include::docstrings/OP_FINISHES.txt[]
 571 ================================
 572
 573 [[OP_PASS]]
 574 [[OP_FAIL]]
 575 [[OP_SKIP]]
 576 === PASS / FAIL / SKIP ===
 577
 578 ================================
 579 ----
 580 (skip &rest REASON-ARGS)
 581 ----
 582
 583 include::docstrings/OP_SKIP.txt[]
 584 ================================
 585
 586 ================================
 587 ----
 588 (pass &rest REASON-ARGS)
 589 ----
 590
 591 include::docstrings/OP_PASS.txt[]
 592 ================================
 593
 594 ================================
 595 ----
 596 (fail &rest REASON-ARGS)
 597 ----
 598
 599 include::docstrings/OP_FAIL.txt[]
 600 ================================
 601
 602 [[OP_-EPOINT-]]
 603 [[OP_-EPOINT--EPOINT-]]
 604 [[OP_-EPOINT--EPOINT--EPOINT-]]
 605
 606 [[OP_RUN-EPOINT-]]
 607 [[OP_EXPLAIN-EPOINT-]]
 608 [[OP_DEBUG-EPOINT-]]
 609 === RUN! / EXPLAIN! / DEBUG! ===
 610
 611 ================================
 612 ----
 613 (run! &optional TEST-NAME)
 614 ----
 615
 616 include::docstrings/OP_RUN-EPOINT-.txt[]
 617 ================================
 618
 619 ================================
 620 ----
 621 (explain! RESULT-LIST)
 622 ----
 623
 624 include::docstrings/OP_EXPLAIN-EPOINT-.txt[]
 625 ================================
 626
 627 ================================
 628 ----
 629 (debug! TEST-NAME)
 630 ----
 631
 632 include::docstrings/OP_DEBUG-EPOINT-.txt[]
 633 ================================
 634
 635 [[OP_RUN]]
 636 === RUN ===
 637
 638 ================================
 639 ----
 640 (run TEST-SPEC)
 641 ----
 642
 643 include::docstrings/OP_RUN.txt[]
 644 ================================
 645
 646 [[OP_DEF-FIXTURE]]
 647 === DEF-FIXTURE ===
 648
 649 ================================
 650 ----
 651 (def-fixture (NAME (&rest ARGS) &body BODY)
 652 ----
 653
 654 include::docstrings/OP_DEF-FIXTURE.txt[]
 655 ================================
 656
 657 [[OP_WITH-FIXTURE]]
 658 === WITH-FIXTURE ===
 659
 660 ================================
 661 ----
 662 (with-fixture NAME (&rest ARGS) &body BODY)
 663 ----
 664
 665 include::docstrings/OP_WITH-FIXTURE.txt[]
 666 ================================
 667
 668 [[OP_FOR-ALL]]
 669 === FOR-ALL ===
 670
 671 ================================
 672 --------------------------------
 673 (for-all (&rest (NAME VALUE &optional GUARD))
 674   &body body)
 675 --------------------------------
 676
 677 include::docstrings/OP_FOR-ALL.txt[]
 678 ================================
 679
 680 [[VAR_-STAR-NUM-TRIALS-STAR-]]
 681 [[VAR_-STAR-MAX-TRIALS-STAR-]]
 682 === \*NUM-TRIALS* / \*MAX-TRIALS* ===
 683
 684 ================================
 685 ----
 686 *num-trials*
 687 ----
 688
 689 include::docstrings/VAR_-STAR-NUM-TRIALS-STAR-.txt[]
 690 ================================
 691
 692 ================================
 693 ----
 694 *max-trials*
 695 ----
 696
 697 include::docstrings/VAR_-STAR-MAX-TRIALS-STAR-.txt[]
 698 ================================
 699
 700 [[OP_GEN-INTEGER]]
 701 [[OP_GEN-FLOAT]]
 702 === GEN-INTEGER / GEN-FLOAT ===
 703
 704 ================================
 705 ----
 706 (gen-integer &key MIN MAX)
 707 ----
 708
 709 include::docstrings/OP_GEN-INTEGER.txt[]
 710 ================================
 711
 712 ================================
 713 ----
 714 (gen-float &key BOUND TYPE MIN MAX)
 715 ----
 716
 717 include::docstrings/OP_GEN-FLOAT.txt[]
 718 ================================
 719
 720 [[OP_GEN-CHARACTER]]
 721 [[OP_GEN-STRING]]
 722 === GEN-CHARACTER / GEN-STRING ===
 723
 724 ================================
 725 ----
 726 (gen-character &key CODE-LIMIT CODE ALPHANUMERICP)
 727 ----
 728
 729 include::docstrings/OP_GEN-CHARACTER.txt[]
 730 ================================
 731
 732 ================================
 733 ----
 734 (gen-string &key LENGTH ELEMENTS)
 735 ----
 736
 737 include::docstrings/OP_GEN-STRING.txt[]
 738 ================================
 739
 740 [[OP_GEN-BUFFER]]
 741 === GEN-BUFFER ===
 742
 743 ================================
 744 ----
 745 (gen-buffer &key LENGTH ELEMENTS ELEMENT-TYPE)
 746 ----
 747
 748 include::docstrings/OP_GEN-STRING.txt[]
 749 ================================
 750
 751 [[OP_GEN-LIST]]
 752 [[OP_GEN-TREE]]
 753 === GEN-LIST / GEN-TREE ===
 754
 755 ================================
 756 ----
 757 (gen-list &key LENGTH ELEMENTS)
 758 ----
 759
 760 include::docstrings/OP_GEN-LIST.txt[]
 761 ================================
 762
 763 ================================
 764
 765 ----
 766 (gen-tree &key SIZE ELEMENTS)
 767 ----
 768
 769 include::docstrings/OP_GEN-TREE.txt[]
 770 ================================
 771
 772 [[OP_GEN-ONE-ELEMENT]]
 773 === GEN-ONE-ELEMENT ===
 774
 775 ================================
 776 ----
 777 (gen-one-element &rest ELEMENTS)
 778 ----
 779
 780 include::docstrings/OP_GEN-ONE-ELEMENT.txt[]
 781 ================================
 782
 783
 784
 785 ////////////////////////////////
 786
 787 ////////////////////////////////