about summary refs log tree commit diff stats
path: root/052tangle.cc
//: A simple test harness. To create new tests, define functions starting with
//: 'test_'. To run all tests so defined, run:
//:   $ ./mu test
//:
//: Every layer should include tests, and can reach into previous layers.
//: However, it seems like a good idea never to reach into tests from previous
//: layers. Every test should be a contract that always passes as originally
//: written, regardless of any later layers. Avoid writing 'temporary' tests
//: that are only meant to work until some layer.

:(before "End Types")
typedef void (*test_fn)(void);
:(before "Globals")
// move a global ahead into types that we can't generate an extern declaration for
const test_fn Tests[] = {
  #include "test_list"  // auto-generated; see 'build*' scripts
};

:(before "End Globals")
bool Run_tests = false;
bool Passed = true;  // set this to false inside any test to indicate failure

:(before "End Includes")
#define CHECK(X) \
  if (Passed && !(X)) { \
    cerr << "\nF - " << __FUNCTION__ << "(" << __FILE__ << ":" << __LINE__ << "): " << #X << '\n'; \
    Passed = false; \
    return;  /* Currently we stop at the very first failure. */ \
  }

#define CHECK_EQ(X, Y) \
  if (Passed && (X) != (Y)) { \
    cerr << "\nF - " << __FUNCTION__ << "(" << __FILE__ << ":" << __LINE__ << "): " << #X << " == " << #Y << '\n'; \
    cerr << "  got " << (X) << '\n';  /* BEWARE: multiple eval */ \
    Passed = false; \
    return;  /* Currently we stop at the very first failure. */ \
  }

:(before "End Reset")
Passed = true;

:(before "End Commandline Parsing")
if (argc > 1 && is_equal(argv[1], "test")) {
  Run_tests = true;  --argc;  ++argv;  // shift 'test' out of commandline args
}

:(before "End Main")
if (Run_tests) {
  // Test Runs
  // we run some tests and then exit; assume no state need be maintained afterward

  long num_failures = 0;
  // End Test Run Initialization
  time_t t;  time(&t);
  cerr << "C tests: " << ctime(&t);
  for (size_t i=0;  i < sizeof(Tests)/sizeof(Tests[0]);  ++i) {
//?     cerr << "running " << Test_names[i] << '\n';
    run_test(i);
    if (Passed) cerr << '.';
    else ++num_failures;
  }
  cerr << '\n';
  // End Tests
  if (num_failures > 0) {
    cerr << num_failures << " failure"
         << (num_failures > 1 ? "s" : "")
         << '\n';
    return 1;
  }
  return 0;
}

:(code)
void run_test(size_t i) {
  if (i >= sizeof(Tests)/sizeof(Tests[0])) {
    cerr << "no test " << i << '\n';
    return;
  }
  reset();
  // End Test Setup
  (*Tests[i])();
  // End Test Teardown
}

//: Convenience: run a single test
:(before "Globals")
// Names for each element of the 'Tests' global, respectively.
const string Test_names[] = {
  #include "test_name_list"  // auto-generated; see 'build*' scripts
};
:(after "Test Runs")
string maybe_single_test_to_run = argv[argc-1];
if (!starts_with(maybe_single_test_to_run, "test_"))
  maybe_single_test_to_run.insert(0, "test_");
for (size_t i=0;  i < sizeof(Tests)/sizeof(Tests[0]);  ++i) {
  if (Test_names[i] == maybe_single_test_to_run) {
    run_test(i);
    if (Passed) cerr << ".\n";
    return 0;
  }
}

:(before "End Includes")
#include <stdlib.h>
Commit message (Collapse)AuthorAgeFilesLines
* 3675Kartik K. Agaram2016-11-151-2/+2
|
* 3552Kartik K. Agaram2016-10-221-2/+1
| | | | | | | | | | | | | | | | | | Stop requiring jump instructions to explicitly provide a ':label' type for jump targets. This has been a source of repeated confusion for my students: a) They'd add the ':label' to the label definition rather than the jump target (label use) b) They'd spend time thinking about whether the initial '+' prefix was part of the label name. In the process I cleaned up a couple of things: - the space of names is more cleanly partitioned into labels and non-labels (clarifying that '_' and '-' are non-label prefixes) - you can't use label names as regular variables anymore - you can infer the type of a label just from its name
* 3549Kartik K. Agaram2016-10-221-12/+16
| | | | | | | | | | | | | | | | | | More consistent definitions for jump targets and waypoints. 1. A label is a word starting with something other than a letter or digit or '$'. 2. A waypoint is a label that starts with '<' and ends with '>'. It has no restrictions. A recipe can define any number of waypoints, and recipes can have duplicate waypoints. 3. The special labels '{' and '}' can also be duplicated any number of times in a recipe. The only constraint on them is that they have to balance in any recipe. Every '{' must be followed by a matching '}'. 4. All other labels are 'jump targets'. You can't have duplicate jump targets in a recipe; that would make jumps ambiguous.
* 3539Kartik K. Agaram2016-10-211-0/+10
u/commit/052tangle.cc?h=hlt&id=2d909c712b014539009d9910cc245ecc9aa4ab93'>2149Kartik K. Agaram2015-09-051-2/+2 | * 2138 - warn on jump to an ambiguous labelKartik K. Agaram2015-09-041-41/+172 | | | | | | | | | | | | | | | | | | | | This seemingly simple goal uncovered a little nest of bugs: it turns out I've been awash in ambiguous labels until now. My baseline recipes in edit.mu were clean, but they introduced duplicate <waypoints> -- and *those* waypoints contained +jump-targets. Result: duplicate jump targets, so that I wasn't jumping where I thought I was jumping. Somehow I happened to be picking one of the alternatives that magically kept these issues quiescent. My first plan to fix this was to mangle names of all labels inside before/after fragments, keep the jump targets private to their fragment. But the labels also include more waypoints! Mangle those, and I can't tangle to them anymore. Solution: harden the convention that jump targets begin with '+' and waypoints are surrounded by '<>'. Mangle jump targets occurring inside before/after fragments to keep them private to their lexical fragment, but *don't* mangle waypoints, which must remain globally accessible. * 2095Kartik K. Agaram2015-08-281-4/+0 | | | | | | | | | | | | Finally terminate the experiment of keeping debug prints around. I'm also going to give up on maintaining counts. What we really need is two kinds of tracing: a) For tests, just the domain-specific facts, organized by labels. b) For debugging, just transient dumps to stdout. b) only works if stdout is clean by default. Hmm, I think this means 'stash' should be the transient kind of trace. * 1945Kartik K. Agaram2015-08-061-19/+68 | | | | | | Turns out it is indeed useful to insert code at multiple duplicate labels within a single (long) recipe. Like handle-keyboard-event in edit.mu. * 1939 - allow nested tanglingKartik K. Agaram2015-08-051-30/+49 | | | | However, you can't have duplicate labels within a single recipe. * 1938 - warn on unused before/after fragmentsKartik K. Agaram2015-08-051-0/+27 | * 1870Kartik K. Agaram2015-07-281-0/+198