From 752e47efe77efc908a51263601eb05e57ebf5130 Mon Sep 17 00:00:00 2001 From: "Kartik K. Agaram" Date: Tue, 15 Mar 2016 11:35:13 -0700 Subject: 2785 --- Readme.md | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/Readme.md b/Readme.md index bbf1b196..dec2b427 100644 --- a/Readme.md +++ b/Readme.md @@ -13,15 +13,20 @@ tests. Hoped-for benefits: In this quest, Mu is currently experimenting with the following mechanisms: -1. New, testable interfaces for the operating system. For example, printing to - screen explicitly takes a screen object, so it can be called on the real - screen, or on a fake screen inside tests, so that we can then check the - expected state of the screen at the end of a test. Here's a test for a - little text-mode chessboard program in Mu (delimiting the edge of the - 'screen' with dots): +1. New, testable interfaces for the operating system. Currently manual tests + are hard to automate because a file you assumed might vanish, the network + might go down, etc. To make manual tests reproducible it suffices to + improve the 15 or so OS syscalls through which a computer talks to the + outside world. We have to allow programs to transparently write to a fake + screen, read from a fake disk/network, etc. In Mu, printing to screen + explicitly takes a screen object, so it can be called on the real screen, + or on a fake screen inside tests, so that we can then check the expected + state of the screen at the end of a test. Here's a test for a little + text-mode chessboard program in Mu (delimiting the edge of the 'screen' + with dots):
      a screen test
We're building up similarly *dependency-injected* interfaces to the - keyboard, mouse, touch screen, disk, network, … + keyboard, mouse, touch screen, disk, network, etc. 1. Support for testing side-effects like performance, deadlock-freedom, race-freeness, memory usage, etc. Mu's *white-box tests* can check not just -- cgit 1.4.1-2-gfad0