FS-Test/README

   1 FS-Test
   2
   3 INSTALLATION
   4
   5 To install this module, install Freeside as usual. Then run the following
   6 commands:
   7
   8         perl Makefile.PL
   9         make
  10         make install
  11
  12 INITIALIZATION
  13
  14 Run "freeside-test-start" from an account that can sudo to root. This will
  15 create a database with the test image and set the system clock to one day
  16 after the last bill. If there's an existing Freeside database, it will be
  17 renamed to "freeside_YYYYMMDD" (the current date).
  18
  19 To restore the system clock and put the existing database back in place,
  20 run "freeside-test-stop".
  21
  22 RUNNING TESTS
  23
  24 "freeside-test-run" is the main test script. Currently there's only one
  25 test plan, "ui_tests". freeside-test-run will:
  26
  27 - download all the URLs listed in the test plan into a directory in /tmp
  28 - compare them to the reference versions with "diff -ur"
  29 - write the output to "freeside_test.YYYYMMDD.diff"
  30 - display the results of "diffstat" on that diff
  31
  32 The raw output directory will not be deleted, so you can examine the results
  33 yourself. This is recommended for files that don't diff nicely like Excel
  34 versions of reports and PDF invoices.
  35
  36 UPDATING THE REFERENCE PAGES
  37
  38 The simplest way to update the reference copies of the test pages is
  39
  40 freeside-test-fetch -d ./share/output
  41
  42 (from the FS-Test source directory). If you're installing from a git repo,
  43 this will overwrite the working tree with the newly downloaded test pages.
  44 You can then use "git diff" to examine your changes and "git commit" to
  45 commit them when you're done.
  46
  47 ADDING NEW TESTS
  48
  49 For UI tests, add the URL, minus the "http://hostname/freeside" prefix,
  50 to share/ui_tests. Then run freeside-test-fetch to get the reference output
  51 of the test and copy it to share/output (and add that file to git).
  52
  53 When adding any new test, make sure to _run it twice_ on the same database
  54 and code version to detect random or time-sensitive variations. These will
  55 throw false alerts when anyone else uses your test, so you'll need to suppress
  56 them somehow.
  57
  58 WHAT'S IN THE TEST DATABASE
  59
  60 Two hundred customers with random nonsensical U.S. addresses. One third have
  61 automatic checking, the rest have credit cards. 10% of the customers have
  62 separate billing and service addresses.
  63
  64 Four package definitions (plus the unique "system domain"): annual domain,
  65 monthly prorated account, monthly prorated broadband service, monthly
  66 phone. Each package has one service except the phone package, which has a
  67 quantity limit of 4. The two monthly prorated packages have setup fees.
  68
  69 Each customer has three of the four packages, started over the period from
  70 2015-08-01 to 2016-03-01. Each package has a service configured (with a random
  71 username, domain name, phone number, or IP address).  Customers were invoiced
  72 on the first day of each month during that period.
  73
  74 There's a billing event to run automatic credit card billing on eligible
  75 invoices. The configured gateway is Business::OnlinePayment::Dummy, which
  76 returns success for everything, so customers with credit cards will be fully
  77 paid.
  78
  79 One user with unlimited access. Username "test", password "test".
  80
  81 There are no cancellations or suspensions, no credits, no taxes, no refunds,
  82 no discounts, no exports, and no RT tickets.  All of this stuff lies in the
  83 bright shining future.
  84
  85 If you modify the test database, be sure to update this section also. Also
  86 update the company name to "Freeside Test X.Y.Z" where X.Y is the Freeside
  87 version number and Z is the test database version number, and set the same
  88 value in freeside-test-start so that old test databases aren't used by
  89 mistake.
  90
  91