t / READMEon commit Merge branch 'cm/diff-check-at-eol' (039e84e)
   1Core GIT Tests
   2==============
   3
   4This directory holds many test scripts for core GIT tools.  The
   5first part of this short document describes how to run the tests
   6and read their output.
   7
   8When fixing the tools or adding enhancements, you are strongly
   9encouraged to add tests in this directory to cover what you are
  10trying to fix or enhance.  The later part of this short document
  11describes how your test scripts should be organized.
  12
  13
  14Running Tests
  15-------------
  16
  17The easiest way to run tests is to say "make".  This runs all
  18the tests.
  19
  20    *** t0000-basic.sh ***
  21    ok 1 - .git/objects should be empty after git init in an empty repo.
  22    ok 2 - .git/objects should have 3 subdirectories.
  23    ok 3 - success is reported like this
  24    ...
  25    ok 43 - very long name in the index handled sanely
  26    # fixed 1 known breakage(s)
  27    # still have 1 known breakage(s)
  28    # passed all remaining 42 test(s)
  29    1..43
  30    *** t0001-init.sh ***
  31    ok 1 - plain
  32    ok 2 - plain with GIT_WORK_TREE
  33    ok 3 - plain bare
  34
  35Since the tests all output TAP (see http://testanything.org) they can
  36be run with any TAP harness. Here's an example of parallel testing
  37powered by a recent version of prove(1):
  38
  39    $ prove --timer --jobs 15 ./t[0-9]*.sh
  40    [19:17:33] ./t0005-signals.sh ................................... ok       36 ms
  41    [19:17:33] ./t0022-crlf-rename.sh ............................... ok       69 ms
  42    [19:17:33] ./t0024-crlf-archive.sh .............................. ok      154 ms
  43    [19:17:33] ./t0004-unwritable.sh ................................ ok      289 ms
  44    [19:17:33] ./t0002-gitfile.sh ................................... ok      480 ms
  45    ===(     102;0  25/?  6/?  5/?  16/?  1/?  4/?  2/?  1/?  3/?  1... )===
  46
  47prove and other harnesses come with a lot of useful options. The
  48--state option in particular is very useful:
  49
  50    # Repeat until no more failures
  51    $ prove -j 15 --state=failed,save ./t[0-9]*.sh
  52
  53You can give DEFAULT_TEST_TARGET=prove on the make command (or define it
  54in config.mak) to cause "make test" to run tests under prove.
  55GIT_PROVE_OPTS can be used to pass additional options, e.g.
  56
  57    $ make DEFAULT_TEST_TARGET=prove GIT_PROVE_OPTS='--timer --jobs 16' test
  58
  59You can also run each test individually from command line, like this:
  60
  61    $ sh ./t3010-ls-files-killed-modified.sh
  62    ok 1 - git update-index --add to add various paths.
  63    ok 2 - git ls-files -k to show killed files.
  64    ok 3 - validate git ls-files -k output.
  65    ok 4 - git ls-files -m to show modified files.
  66    ok 5 - validate git ls-files -m output.
  67    # passed all 5 test(s)
  68    1..5
  69
  70You can pass --verbose (or -v), --debug (or -d), and --immediate
  71(or -i) command line argument to the test, or by setting GIT_TEST_OPTS
  72appropriately before running "make".
  73
  74--verbose::
  75        This makes the test more verbose.  Specifically, the
  76        command being run and their output if any are also
  77        output.
  78
  79--debug::
  80        This may help the person who is developing a new test.
  81        It causes the command defined with test_debug to run.
  82
  83--immediate::
  84        This causes the test to immediately exit upon the first
  85        failed test.
  86
  87--long-tests::
  88        This causes additional long-running tests to be run (where
  89        available), for more exhaustive testing.
  90
  91--valgrind::
  92        Execute all Git binaries with valgrind and exit with status
  93        126 on errors (just like regular tests, this will only stop
  94        the test script when running under -i).  Valgrind errors
  95        go to stderr, so you might want to pass the -v option, too.
  96
  97        Since it makes no sense to run the tests with --valgrind and
  98        not see any output, this option implies --verbose.  For
  99        convenience, it also implies --tee.
 100
 101--tee::
 102        In addition to printing the test output to the terminal,
 103        write it to files named 't/test-results/$TEST_NAME.out'.
 104        As the names depend on the tests' file names, it is safe to
 105        run the tests with this option in parallel.
 106
 107--with-dashes::
 108        By default tests are run without dashed forms of
 109        commands (like git-commit) in the PATH (it only uses
 110        wrappers from ../bin-wrappers).  Use this option to include
 111        the build directory (..) in the PATH, which contains all
 112        the dashed forms of commands.  This option is currently
 113        implied by other options like --valgrind and
 114        GIT_TEST_INSTALLED.
 115
 116--root=<directory>::
 117        Create "trash" directories used to store all temporary data during
 118        testing under <directory>, instead of the t/ directory.
 119        Using this option with a RAM-based filesystem (such as tmpfs)
 120        can massively speed up the test suite.
 121
 122You can also set the GIT_TEST_INSTALLED environment variable to
 123the bindir of an existing git installation to test that installation.
 124You still need to have built this git sandbox, from which various
 125test-* support programs, templates, and perl libraries are used.
 126If your installed git is incomplete, it will silently test parts of
 127your built version instead.
 128
 129When using GIT_TEST_INSTALLED, you can also set GIT_TEST_EXEC_PATH to
 130override the location of the dashed-form subcommands (what
 131GIT_EXEC_PATH would be used for during normal operation).
 132GIT_TEST_EXEC_PATH defaults to `$GIT_TEST_INSTALLED/git --exec-path`.
 133
 134
 135Skipping Tests
 136--------------
 137
 138In some environments, certain tests have no way of succeeding
 139due to platform limitation, such as lack of 'unzip' program, or
 140filesystem that do not allow arbitrary sequence of non-NUL bytes
 141as pathnames.
 142
 143You should be able to say something like
 144
 145    $ GIT_SKIP_TESTS=t9200.8 sh ./t9200-git-cvsexport-commit.sh
 146
 147and even:
 148
 149    $ GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' make
 150
 151to omit such tests.  The value of the environment variable is a
 152SP separated list of patterns that tells which tests to skip,
 153and either can match the "t[0-9]{4}" part to skip the whole
 154test, or t[0-9]{4} followed by ".$number" to say which
 155particular test to skip.
 156
 157Note that some tests in the existing test suite rely on previous
 158test item, so you cannot arbitrarily disable one and expect the
 159remainder of test to check what the test originally was intended
 160to check.
 161
 162
 163Naming Tests
 164------------
 165
 166The test files are named as:
 167
 168        tNNNN-commandname-details.sh
 169
 170where N is a decimal digit.
 171
 172First digit tells the family:
 173
 174        0 - the absolute basics and global stuff
 175        1 - the basic commands concerning database
 176        2 - the basic commands concerning the working tree
 177        3 - the other basic commands (e.g. ls-files)
 178        4 - the diff commands
 179        5 - the pull and exporting commands
 180        6 - the revision tree commands (even e.g. merge-base)
 181        7 - the porcelainish commands concerning the working tree
 182        8 - the porcelainish commands concerning forensics
 183        9 - the git tools
 184
 185Second digit tells the particular command we are testing.
 186
 187Third digit (optionally) tells the particular switch or group of switches
 188we are testing.
 189
 190If you create files under t/ directory (i.e. here) that is not
 191the top-level test script, never name the file to match the above
 192pattern.  The Makefile here considers all such files as the
 193top-level test script and tries to run all of them.  A care is
 194especially needed if you are creating a common test library
 195file, similar to test-lib.sh, because such a library file may
 196not be suitable for standalone execution.
 197
 198
 199Writing Tests
 200-------------
 201
 202The test script is written as a shell script.  It should start
 203with the standard "#!/bin/sh" with copyright notices, and an
 204assignment to variable 'test_description', like this:
 205
 206        #!/bin/sh
 207        #
 208        # Copyright (c) 2005 Junio C Hamano
 209        #
 210
 211        test_description='xxx test (option --frotz)
 212
 213        This test registers the following structure in the cache
 214        and tries to run git-ls-files with option --frotz.'
 215
 216
 217Source 'test-lib.sh'
 218--------------------
 219
 220After assigning test_description, the test script should source
 221test-lib.sh like this:
 222
 223        . ./test-lib.sh
 224
 225This test harness library does the following things:
 226
 227 - If the script is invoked with command line argument --help
 228   (or -h), it shows the test_description and exits.
 229
 230 - Creates an empty test directory with an empty .git/objects database
 231   and chdir(2) into it.  This directory is 't/trash
 232   directory.$test_name_without_dotsh', with t/ subject to change by
 233   the --root option documented above.
 234
 235 - Defines standard test helper functions for your scripts to
 236   use.  These functions are designed to make all scripts behave
 237   consistently when command line arguments --verbose (or -v),
 238   --debug (or -d), and --immediate (or -i) is given.
 239
 240Do's, don'ts & things to keep in mind
 241-------------------------------------
 242
 243Here are a few examples of things you probably should and shouldn't do
 244when writing tests.
 245
 246Do:
 247
 248 - Put all code inside test_expect_success and other assertions.
 249
 250   Even code that isn't a test per se, but merely some setup code
 251   should be inside a test assertion.
 252
 253 - Chain your test assertions
 254
 255   Write test code like this:
 256
 257        git merge foo &&
 258        git push bar &&
 259        test ...
 260
 261   Instead of:
 262
 263        git merge hla
 264        git push gh
 265        test ...
 266
 267   That way all of the commands in your tests will succeed or fail. If
 268   you must ignore the return value of something, consider using a
 269   helper function (e.g. use sane_unset instead of unset, in order
 270   to avoid unportable return value for unsetting a variable that was
 271   already unset), or prepending the command with test_might_fail or
 272   test_must_fail.
 273
 274 - Check the test coverage for your tests. See the "Test coverage"
 275   below.
 276
 277   Don't blindly follow test coverage metrics, they're a good way to
 278   spot if you've missed something. If a new function you added
 279   doesn't have any coverage you're probably doing something wrong,
 280   but having 100% coverage doesn't necessarily mean that you tested
 281   everything.
 282
 283   Tests that are likely to smoke out future regressions are better
 284   than tests that just inflate the coverage metrics.
 285
 286Don't:
 287
 288 - exit() within a <script> part.
 289
 290   The harness will catch this as a programming error of the test.
 291   Use test_done instead if you need to stop the tests early (see
 292   "Skipping tests" below).
 293
 294 - Break the TAP output
 295
 296   The raw output from your test may be interpreted by a TAP harness. TAP
 297   harnesses will ignore everything they don't know about, but don't step
 298   on their toes in these areas:
 299
 300   - Don't print lines like "$x..$y" where $x and $y are integers.
 301
 302   - Don't print lines that begin with "ok" or "not ok".
 303
 304   TAP harnesses expect a line that begins with either "ok" and "not
 305   ok" to signal a test passed or failed (and our harness already
 306   produces such lines), so your script shouldn't emit such lines to
 307   their output.
 308
 309   You can glean some further possible issues from the TAP grammar
 310   (see http://search.cpan.org/perldoc?TAP::Parser::Grammar#TAP_Grammar)
 311   but the best indication is to just run the tests with prove(1),
 312   it'll complain if anything is amiss.
 313
 314Keep in mind:
 315
 316 - Inside <script> part, the standard output and standard error
 317   streams are discarded, and the test harness only reports "ok" or
 318   "not ok" to the end user running the tests. Under --verbose, they
 319   are shown to help debugging the tests.
 320
 321
 322Skipping tests
 323--------------
 324
 325If you need to skip tests you should do so be using the three-arg form
 326of the test_* functions (see the "Test harness library" section
 327below), e.g.:
 328
 329    test_expect_success PERL 'I need Perl' "
 330        '$PERL_PATH' -e 'hlagh() if unf_unf()'
 331    "
 332
 333The advantage of skipping tests like this is that platforms that don't
 334have the PERL and other optional dependencies get an indication of how
 335many tests they're missing.
 336
 337If the test code is too hairy for that (i.e. does a lot of setup work
 338outside test assertions) you can also skip all remaining tests by
 339setting skip_all and immediately call test_done:
 340
 341        if ! test_have_prereq PERL
 342        then
 343            skip_all='skipping perl interface tests, perl not available'
 344            test_done
 345        fi
 346
 347The string you give to skip_all will be used as an explanation for why
 348the test was skipped.
 349
 350End with test_done
 351------------------
 352
 353Your script will be a sequence of tests, using helper functions
 354from the test harness library.  At the end of the script, call
 355'test_done'.
 356
 357
 358Test harness library
 359--------------------
 360
 361There are a handful helper functions defined in the test harness
 362library for your script to use.
 363
 364 - test_expect_success [<prereq>] <message> <script>
 365
 366   Usually takes two strings as parameter, and evaluates the
 367   <script>.  If it yields success, test is considered
 368   successful.  <message> should state what it is testing.
 369
 370   Example:
 371
 372        test_expect_success \
 373            'git-write-tree should be able to write an empty tree.' \
 374            'tree=$(git-write-tree)'
 375
 376   If you supply three parameters the first will be taken to be a
 377   prerequisite, see the test_set_prereq and test_have_prereq
 378   documentation below:
 379
 380        test_expect_success TTY 'git --paginate rev-list uses a pager' \
 381            ' ... '
 382
 383   You can also supply a comma-separated list of prerequisites, in the
 384   rare case where your test depends on more than one:
 385
 386        test_expect_success PERL,PYTHON 'yo dawg' \
 387            ' test $(perl -E 'print eval "1 +" . qx[python -c "print 2"]') == "4" '
 388
 389 - test_expect_failure [<prereq>] <message> <script>
 390
 391   This is NOT the opposite of test_expect_success, but is used
 392   to mark a test that demonstrates a known breakage.  Unlike
 393   the usual test_expect_success tests, which say "ok" on
 394   success and "FAIL" on failure, this will say "FIXED" on
 395   success and "still broken" on failure.  Failures from these
 396   tests won't cause -i (immediate) to stop.
 397
 398   Like test_expect_success this function can optionally use a three
 399   argument invocation with a prerequisite as the first argument.
 400
 401 - test_debug <script>
 402
 403   This takes a single argument, <script>, and evaluates it only
 404   when the test script is started with --debug command line
 405   argument.  This is primarily meant for use during the
 406   development of a new test script.
 407
 408 - test_done
 409
 410   Your test script must have test_done at the end.  Its purpose
 411   is to summarize successes and failures in the test script and
 412   exit with an appropriate error code.
 413
 414 - test_tick
 415
 416   Make commit and tag names consistent by setting the author and
 417   committer times to defined stated.  Subsequent calls will
 418   advance the times by a fixed amount.
 419
 420 - test_commit <message> [<filename> [<contents>]]
 421
 422   Creates a commit with the given message, committing the given
 423   file with the given contents (default for both is to reuse the
 424   message string), and adds a tag (again reusing the message
 425   string as name).  Calls test_tick to make the SHA-1s
 426   reproducible.
 427
 428 - test_merge <message> <commit-or-tag>
 429
 430   Merges the given rev using the given message.  Like test_commit,
 431   creates a tag and calls test_tick before committing.
 432
 433 - test_set_prereq SOME_PREREQ
 434
 435   Set a test prerequisite to be used later with test_have_prereq. The
 436   test-lib will set some prerequisites for you, see the
 437   "Prerequisites" section below for a full list of these.
 438
 439   Others you can set yourself and use later with either
 440   test_have_prereq directly, or the three argument invocation of
 441   test_expect_success and test_expect_failure.
 442
 443 - test_have_prereq SOME PREREQ
 444
 445   Check if we have a prerequisite previously set with
 446   test_set_prereq. The most common use of this directly is to skip
 447   all the tests if we don't have some essential prerequisite:
 448
 449        if ! test_have_prereq PERL
 450        then
 451            skip_all='skipping perl interface tests, perl not available'
 452            test_done
 453        fi
 454
 455 - test_external [<prereq>] <message> <external> <script>
 456
 457   Execute a <script> with an <external> interpreter (like perl). This
 458   was added for tests like t9700-perl-git.sh which do most of their
 459   work in an external test script.
 460
 461        test_external \
 462            'GitwebCache::*FileCache*' \
 463            "$PERL_PATH" "$TEST_DIRECTORY"/t9503/test_cache_interface.pl
 464
 465   If the test is outputting its own TAP you should set the
 466   test_external_has_tap variable somewhere before calling the first
 467   test_external* function. See t9700-perl-git.sh for an example.
 468
 469        # The external test will outputs its own plan
 470        test_external_has_tap=1
 471
 472 - test_external_without_stderr [<prereq>] <message> <external> <script>
 473
 474   Like test_external but fail if there's any output on stderr,
 475   instead of checking the exit code.
 476
 477        test_external_without_stderr \
 478            'Perl API' \
 479            "$PERL_PATH" "$TEST_DIRECTORY"/t9700/test.pl
 480
 481 - test_expect_code <exit-code> <command>
 482
 483   Run a command and ensure that it exits with the given exit code.
 484   For example:
 485
 486        test_expect_success 'Merge with d/f conflicts' '
 487                test_expect_code 1 git merge "merge msg" B master
 488        '
 489
 490 - test_must_fail <git-command>
 491
 492   Run a git command and ensure it fails in a controlled way.  Use
 493   this instead of "! <git-command>".  When git-command dies due to a
 494   segfault, test_must_fail diagnoses it as an error; "! <git-command>"
 495   treats it as just another expected failure, which would let such a
 496   bug go unnoticed.
 497
 498 - test_might_fail <git-command>
 499
 500   Similar to test_must_fail, but tolerate success, too.  Use this
 501   instead of "<git-command> || :" to catch failures due to segv.
 502
 503 - test_cmp <expected> <actual>
 504
 505   Check whether the content of the <actual> file matches the
 506   <expected> file.  This behaves like "cmp" but produces more
 507   helpful output when the test is run with "-v" option.
 508
 509 - test_line_count (= | -lt | -ge | ...) <length> <file>
 510
 511   Check whether a file has the length it is expected to.
 512
 513 - test_path_is_file <file> [<diagnosis>]
 514   test_path_is_dir <dir> [<diagnosis>]
 515   test_path_is_missing <path> [<diagnosis>]
 516
 517   Check whether a file/directory exists or doesn't. <diagnosis> will
 518   be displayed if the test fails.
 519
 520 - test_when_finished <script>
 521
 522   Prepend <script> to a list of commands to run to clean up
 523   at the end of the current test.  If some clean-up command
 524   fails, the test will not pass.
 525
 526   Example:
 527
 528        test_expect_success 'branch pointing to non-commit' '
 529                git rev-parse HEAD^{tree} >.git/refs/heads/invalid &&
 530                test_when_finished "git update-ref -d refs/heads/invalid" &&
 531                ...
 532        '
 533
 534Prerequisites
 535-------------
 536
 537These are the prerequisites that the test library predefines with
 538test_have_prereq.
 539
 540See the prereq argument to the test_* functions in the "Test harness
 541library" section above and the "test_have_prereq" function for how to
 542use these, and "test_set_prereq" for how to define your own.
 543
 544 - PERL & PYTHON
 545
 546   Git wasn't compiled with NO_PERL=YesPlease or
 547   NO_PYTHON=YesPlease. Wrap any tests that need Perl or Python in
 548   these.
 549
 550 - POSIXPERM
 551
 552   The filesystem supports POSIX style permission bits.
 553
 554 - BSLASHPSPEC
 555
 556   Backslashes in pathspec are not directory separators. This is not
 557   set on Windows. See 6fd1106a for details.
 558
 559 - EXECKEEPSPID
 560
 561   The process retains the same pid across exec(2). See fb9a2bea for
 562   details.
 563
 564 - SYMLINKS
 565
 566   The filesystem we're on supports symbolic links. E.g. a FAT
 567   filesystem doesn't support these. See 704a3143 for details.
 568
 569 - SANITY
 570
 571   Test is not run by root user, and an attempt to write to an
 572   unwritable file is expected to fail correctly.
 573
 574Tips for Writing Tests
 575----------------------
 576
 577As with any programming projects, existing programs are the best
 578source of the information.  However, do _not_ emulate
 579t0000-basic.sh when writing your tests.  The test is special in
 580that it tries to validate the very core of GIT.  For example, it
 581knows that there will be 256 subdirectories under .git/objects/,
 582and it knows that the object ID of an empty tree is a certain
 58340-byte string.  This is deliberately done so in t0000-basic.sh
 584because the things the very basic core test tries to achieve is
 585to serve as a basis for people who are changing the GIT internal
 586drastically.  For these people, after making certain changes,
 587not seeing failures from the basic test _is_ a failure.  And
 588such drastic changes to the core GIT that even changes these
 589otherwise supposedly stable object IDs should be accompanied by
 590an update to t0000-basic.sh.
 591
 592However, other tests that simply rely on basic parts of the core
 593GIT working properly should not have that level of intimate
 594knowledge of the core GIT internals.  If all the test scripts
 595hardcoded the object IDs like t0000-basic.sh does, that defeats
 596the purpose of t0000-basic.sh, which is to isolate that level of
 597validation in one place.  Your test also ends up needing
 598updating when such a change to the internal happens, so do _not_
 599do it and leave the low level of validation to t0000-basic.sh.
 600
 601Test coverage
 602-------------
 603
 604You can use the coverage tests to find code paths that are not being
 605used or properly exercised yet.
 606
 607To do that, run the coverage target at the top-level (not in the t/
 608directory):
 609
 610    make coverage
 611
 612That'll compile Git with GCC's coverage arguments, and generate a test
 613report with gcov after the tests finish. Running the coverage tests
 614can take a while, since running the tests in parallel is incompatible
 615with GCC's coverage mode.
 616
 617After the tests have run you can generate a list of untested
 618functions:
 619
 620    make coverage-untested-functions
 621
 622You can also generate a detailed per-file HTML report using the
 623Devel::Cover module. To install it do:
 624
 625   # On Debian or Ubuntu:
 626   sudo aptitude install libdevel-cover-perl
 627
 628   # From the CPAN with cpanminus
 629   curl -L http://cpanmin.us | perl - --sudo --self-upgrade
 630   cpanm --sudo Devel::Cover
 631
 632Then, at the top-level:
 633
 634    make cover_db_html
 635
 636That'll generate a detailed cover report in the "cover_db_html"
 637directory, which you can then copy to a webserver, or inspect locally
 638in a browser.
 639
 640Smoke testing
 641-------------
 642
 643The Git test suite has support for smoke testing. Smoke testing is
 644when you submit the results of a test run to a central server for
 645analysis and aggregation.
 646
 647Running a smoke tester is an easy and valuable way of contributing to
 648Git development, particularly if you have access to an uncommon OS on
 649obscure hardware.
 650
 651After building Git you can generate a smoke report like this in the
 652"t" directory:
 653
 654    make clean smoke
 655
 656You can also pass arguments via the environment. This should make it
 657faster:
 658
 659    GIT_TEST_OPTS='--root=/dev/shm' TEST_JOBS=10 make clean smoke
 660
 661The "smoke" target will run the Git test suite with Perl's
 662"TAP::Harness" module, and package up the results in a .tar.gz archive
 663with "TAP::Harness::Archive". The former is included with Perl v5.10.1
 664or later, but you'll need to install the latter from the CPAN. See the
 665"Test coverage" section above for how you might do that.
 666
 667Once the "smoke" target finishes you'll see a message like this:
 668
 669    TAP Archive created at <path to git>/t/test-results/git-smoke.tar.gz
 670
 671To upload the smoke report you need to have curl(1) installed, then
 672do:
 673
 674    make smoke_report
 675
 676To upload the report anonymously. Hopefully that'll return something
 677like "Reported #7 added.".
 678
 679If you're going to be uploading reports frequently please request a
 680user account by E-Mailing gitsmoke@v.nix.is. Once you have a username
 681and password you'll be able to do:
 682
 683    SMOKE_USERNAME=<username> SMOKE_PASSWORD=<password> make smoke_report
 684
 685You can also add an additional comment to attach to the report, and/or
 686a comma separated list of tags:
 687
 688    SMOKE_USERNAME=<username> SMOKE_PASSWORD=<password> \
 689        SMOKE_COMMENT=<comment> SMOKE_TAGS=<tags> \
 690        make smoke_report
 691
 692Once the report is uploaded it'll be made available at
 693http://smoke.git.nix.is, here's an overview of Recent Smoke Reports
 694for Git:
 695
 696    http://smoke.git.nix.is/app/projects/smoke_reports/1
 697
 698The reports will also be mirrored to GitHub every few hours:
 699
 700    http://github.com/gitsmoke/smoke-reports
 701
 702The Smolder SQLite database is also mirrored and made available for
 703download:
 704
 705    http://github.com/gitsmoke/smoke-database
 706
 707Note that the database includes hashed (with crypt()) user passwords
 708and E-Mail addresses. Don't use a valuable password for the smoke
 709service if you have an account, or an E-Mail address you don't want to
 710be publicly known. The user accounts are just meant to be convenient
 711labels, they're not meant to be secure.