// The goal of this skeleton is to make programs more easy to understand and // more malleable, easy to rewrite in radical ways without accidentally // breaking some corner case. Tests further both goals. They help // understandability by letting one make small changes and get feedback. What // if I wrote this line like so? What if I removed this function call, is it // really necessary? Just try it, see if the tests pass. Want to explore // rewriting this bit in this way? Tests put many refactorings on a firmer // footing. // // But the usual way we write tests seems incomplete. Refactorings tend to // work in the small, but don't help with changes to function boundaries. If // you want to extract a new function you have to manually test-drive it to // create tests for it. If you want to inline a function its tests are no // longer valid. In both cases you end up having to reorganize code as well as // tests, an error-prone activity. // // This file tries to fix this problem by supporting domain-driven testing // rather than coverage-driven testing. The goal isn't to test all possible // paths in the code any longer, but to focus on the domain of inputs the // program should work on. All tests invoke the program in a single way: by // calling run() with different inputs. The program operates on the input and // logs _facts_ it deduces to a trace: // trace("label") << "fact 1: " << val; // // The tests check for facts: // :(scenario foo) // 34 # call run() with this input // +label: fact 1: 34 # trace should have logged this at the end // -label: fact 1: 35 # trace should never contain such a line // // Since we never call anything but the run() function directly, we never have // to rewrite the tests when we reorganize the internals of the program. We // just have to make sure our rewrite deduces the same facts about the domain, // and that's something we're going to have to do anyway. // // To avoid the combinatorial explosion of integration tests, we organize the // program into different layers, and each fact is logged to the trace with a // specific label. Individual tests can focus on specific labels. In essence, // validating the facts logged with a specific label is identical to calling // some internal subsystem. // // Traces interact salubriously with layers. Thanks to our ordering // directives, each layer can contain its own tests. They may rely on other // layers, but when a test fails its usually due to breakage in the same // layer. When multiple tests fail, it's usually useful to debug the very // first test to fail. This is in contrast with the traditional approach, // where changes can cause breakages in faraway subsystems, and picking the // right test to debug can be an important skill to pick up. // // A final wrinkle is for recursive functions; it's often useful to segment // calls of different depth in the trace: // +eval/1: => 34 # the topmost call to eval should have logged this line // (look at new_trace_frame below) // // To build robust tests, trace facts about your domain rather than details of // how you computed them. // // More details: http://akkartik.name/blog/tracing-tests // // --- // // Between layers and domain-driven testing, programming starts to look like a // fundamentally different activity. Instead of a) superficial, b) local rules // on c) code [like http://blog.bbv.ch/2013/06/05/clean-code-cheat-sheet], // we allow programmers to engage with the a) deep, b) global structure of the // c) domain. If you can systematically track discontinuities in the domain // you don't care if the code used gotos as long as it passed the tests. If // tests become more robust to run it becomes easier to try out radically // different implementations for the same program. If code is super-easy to // rewrite, it becomes less important what indentation style it uses, or that // the objects are appropriately encapsulated, or that the functions are // referentially transparent. // // Instead of plumbing, programming becomes building and gradually refining a // map of the environment the program must operate under. Whether a program is // 'correct' at a given point in time is a red herring; what matters is // avoiding regression by monotonically nailing down the more 'eventful' parts // of the terrain. It helps readers new and old and rewards curiosity to // organize large programs in self-similar hiearchies of example scenarios // colocated with the code that makes them work. // // "Programming properly should be regarded as an activity by which // programmers form a mental model, rather than as production of a program." // -- Peter Naur (http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn,+Musashi%22) :(before "int main") // End Tracing // hack to ensure most code in this layer comes before anything else :(before "End Tracing") bool Hide_warnings = false; :(before "End Setup") Hide_warnings = false; :(before "End Tracing") struct trace_stream { vector > > past_lines; // [(layer label, frame, line)] unordered_map frame; // accumulator for current line ostringstream* curr_stream; string curr_layer; string dump_layer; trace_stream() :curr_stream(NULL) {} ~trace_stream() { if (curr_stream) delete curr_stream; } ostringstream& stream(string layer) { newline(); curr_stream = new ostringstream; curr_layer = layer; return *curr_stream; } // be sure to call this before messing with curr_stream or curr_layer or frame void newline() { if (!curr_stream) return; past_lines.push_back(pair >(curr_layer, pair(frame[curr_layer], curr_stream->str()))); if (curr_layer == dump_layer || curr_layer == "dump" || (!Hide_warnings && curr_layer == "warn")) cerr << frame[curr_layer] << ": " << with_newline(curr_stream->str()); delete curr_stream; curr_stream = NULL; } // Useful for debugging. string readable_contents(string layer) { // missing layer = everything, frame, hierarchical layers newline(); ostringstream output; string real_layer, frame; parse_layer_and_frame(layer, &real_layer, &frame); for (vector > >::iterator p = past_lines.begin(); p != past_lines.end(); ++p) if (layer.empty() || prefix_match(real_layer, p->first)) output << p->first << "/" << p->second.first << ": " << with_newline(p->second.second); return output.str(); } // Useful for a newcomer to visualize the program at work. void dump_browseable_contents(string layer) { ofstream dump("dump"); dump << "
start
\n"; for (vector > >::iterator p = past_lines.begin(); p != past_lines.end(); ++p) { if (p->first != layer) continue; dump << "
"; dump << p->second.second; dump << "
\n"; } dump.close(); } string with_newline(string s) { if (s[s.size()-1] != '\n') return s+'\n'; return s; } }; trace_stream* Trace_stream = NULL; // Top-level helper. IMPORTANT: can't nest. #define trace(layer) !Trace_stream ? cerr /*print nothing*/ : Trace_stream->stream(layer) // Warnings should go straight to cerr by default since calls to trace() have // some unfriendly constraints (they delay printing, they can't nest) #define raise ((!Trace_stream || !Hide_warnings) ? cerr /*do print*/ : Trace_s
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Mu - 068random.mu</title>
<meta name="Generator" content="Vim/8.0">
<meta name="plugin-version" content="vim7.4_v2">
<meta name="syntax" content="none">
<meta name="settings" content="number_lines,use_css,pre_wrap,no_foldcolumn,expand_tabs,line_ids,prevent_copy=">
<meta name="colorscheme" content="minimal-light">
<style type="text/css">
<!--
pre { white-space: pre-wrap; font-family: monospace; color: #000000; background-color: #c6c6c6; }
body { font-size:12pt; font-family: monospace; color: #000000; background-color: #c6c6c6; }
a { color:inherit; }
* { font-size:12pt; font-size: 1em; }
.muControl { color: #804000; }
.muRecipe { color: #ff8700; }