-*-org -*-

* env: ability to read multiline string
<2018-07-08 Sun>
Currently reads just single line.
* Ref Man: Concept "symbol"
Examples of symbol references may now use new lines in instr args
to improve readability.
* Ref Man FILE-CONTENTS-MATCHER / num-lines
<2018-04-05 tor>
Describe how lines are counted.
Tell that a final new-line does not count as a line, i.e.
both of these strings have 1 line:
 "a"
 "a\n"

So each newling "belong" to the line consisting of the non-new-line characters
preceding it.
* Ref Man: GLOB-PATTERN: Describe actual syntax and semantics
<2018-04-05 tor>
Now it just mentions that it is a "shell glob pattern".
It would be helpful to also see the syntax and what it does,
since the user may not be familiar with glob pattnerns
(even thoug that is quite unlikely).
* Introduce Line/FileMatcherValue as DirDepVal
<2018-04-05 tor>
All other symbol types have three forms
 - Resolver        FileRefResolver
 - Value           FileRef
 - primitive value pathlib.Path

And the Value form gives access to the TCDS.
Having the same structure for all types makes the structure simpler.
* remove setup/validate_post_setup
<2017-12-10 Sun>
It is confusing that an instruction can report VALIDATION_ERROR
after the execution has started - i.e. after some "heavy" setup may have
taken place (e.g. populating a db) that needs cleanup.
* define file/line check as exec of process (via run / shell instructions)
<2017-11-25 Sat>
Exactly has limited functionality for assertions, and exec of external programs
is a way to overcome this.

The reason for having assertions (and other things) as external programs
is to make it possible to use parts of Exactly that are usefull, but still
be able to do the custom things that Exactly cannot.

One such feature of Exactly that it would be good to utilize is
the "dir-contents" assertion, and it's quantification over files.
It would be great if custom assertion could be quantified, e.g.
For example

--------------------
dir-contents my-dir 
            --selection S any file :
            ! --transformed T
            custom-assertion MY_CUSTOM_ASSERTION
--------------------

--------------------
dir-contents my-dir 
            --selection S any file :
            custom-assertion MY_CUSTOM_ASSERTION
--------------------

The program would get the file name as the first/last argument.
* Test of signals (or is this OS specific)?
<2017-11-19 sön>
Seem like a reasonable thing for E to test.
* Make "preprocessor" a configuration parameter
It is also a conf param, but for suites.
* new instr to create symlink (complement to "file", "dir")
<2017-10-06 Fri>

symlink DESTINATION [SOURCE]

SOURCE is optional, so that it is possible to create
broken sym-links.
* division of responsibilities between default MainProgram and the super class
<2017-09-01 Fri>
# NOTE: The division of responsibilities between this class and
# the super class does not feel natural:
# * This class - the default - defines the case / suite functionality after cli arguments
#   have been parsed.
# * The super class parses arguments - why?
# * This class is configurable in terms of instructions - so those are not "default"

* remove / replace --rel-cd relativity?
<2017-08-19 Sat>
It doesn't fit together with the other roots that has a RelOptionType,
since it does not produce an absolute path.  This causes some problems
in the implementation, althoug quite small.

Today, there is special treatment of hard coded absolute paths:
these does not have a RelOptionType, and information about them
is represented in a special way only used for these abs paths:

----------------------------------------
class PathRelativityVariants:

    @property
    def rel_option_types(self) -> set:

    @property
    def absolute(self) -> bool:
----------------------------------------

Maybe it would make the code more consistent to move
info about --rel-cd to the bucket for abs relativity. I.e.
these two relativities would be treated with equal special handling,
that would indicate that they are not any of the relativity roots.

With that approach. RelNonHomeOptionType could be discarded.

What makes --rel-cd fit in RelOptionType is probably the fact that
it has a command line option "--rel-cd".  So RelOptionType represent
all "roots" with a relativity option.

Maybe --rel-cd should be removed.  But there must be some way to
specify paths relative the cd. So if it were removed, it would
mean that no PATH argument could have a default relativity other than
--rel-cd.

Another option is to split RelOptionType into two: one set
that is identical to todays, and one with only real-relativities.

Another option is to change how accepted options are given to
parse_file_ref.
** Change RelOptionType to just be the set of relativity-options?
<2017-08-20 Sun>

I.e., change it to be what the name says!
Introduce other enums for relativity roots, e.g.
RelativityRoot
* DONE type instruction should use standard parse_file_ref
Currently it only supports paths relative CD.
* install instruction
** should parse file name using parse_file_ref
** should check parsed file using FileRefCheck
As done by InstructionWithFileRefsBase
* symbols
** functionlity for listing and disp value of all symbols in TC
<2017-11-11 lör>
Functionallity for displaying symbol info:
*** Functions
**** list all symbols defined in the test case (not builtin symbol)
--------------------
Line X: string MY_SYM = "the value"
Line Y: path   MY_P   = EXACTLY_ACT/the/resolved/path
--------------------
**** display detailed info about a specific symbol
Display at least three things:
 - top level definition
   Line X: path MY_P = --rel PATH_SYM @[S]@

 - all involved symbols

   path MY_P = @[PS1]@/@[PS2]@/@[S1]@/constant/@[S2]@

 - resolved value
   
   EXACTLY_ACT/the_ps1/the_ps2/the_s1/constant/the_s2

*** Command line syntax
CL options / new mode for symbol info.
Curent modes:
 - test case (default)
 - suite
 - help

A new mode would be nice.  But this mode would need to allow options and
arguments for specifying a test case file etc:
 - test case file
 - preprocessor
 - suite (--suite SUITE)
*** Relation to other functionallity
The --act CLO invokes a similair alternative way of "looking at a test case".
There could/should also be a similair functionality to run a test case "dry",
that prints instructions and arguments instead of executing them.
All these alternative ways of executing a test case maybe should have some
common syntax.
** def of FileRef should let context of use determine default relativity
The "def" instruction should not specify default relativity.
The default relativity is determined by instructions that use file refs -
they try to make a default that is probably most convenient.
Since the "def" instruction does not use the file-ref, it cannot know what
the best default is.
Also, since use-instructions specify a default, it is confusing to let
the "def" instruction specify it

At the same time, the "def" instruction may set relativity, by giving
it explicitly.

A solution may need to let two kind of file-refs reside in the sym-tbl:
 - ordinary FileRef (with fixed relativity)
 - relative paths only consisting of a relative path-suffix
   Relativity of the path-suffix is determined by each using instruction.
** possibility to use custom delimiters for symbols
e.g. in here-docs:

file f --symbol-syntax BEGIN_DELIM END_DELMI <<EOF
@[this_should_not_be_substitiuted_by_symbol]@
EOF

Today it is impossible to show that symbol values are not
substituted inside hard quotes:

----------------------------------------
[setup]

def string MY_SYMBOL = '@[SYM_REF_SYNTAX_INSIDE_HARD_QUOTES]@'

[act]

print-command-line-arguments @[MY_SYMBOL]@
[assert]

stdout equals <<EOF
@[SYM_REF_SYNTAX_INSIDE_HARD_QUOTES]@
EOF
----------------------------------------

stdout will not validate, since it referes to an undefined symbol.

* instr for setting conf params: is there a better syntax? use = ?
<2017-11-11 lör>
Current syntax is maybe difficult to understand:
--------------------
home ..
act-home ../my-dir
actor --interpreter ...
--------------------
What these instructions do is to set configuration parameters,
and the de facto syntax for setting things is to use =
(in both functional and non-functional languages (sometimes := in non-f lng))
** Variants
*** use =
--------------------
[conf]
home		= ..
act-home	= ../my-dir
actor		= --interpreter ...

status		= SKIP
--------------------
+ clear that this is setting a property
- may be confusing since the property name serves as instruction name.
  but this may be ok, since these instructions exist in a separate phase
  "conf" which may indicate that these are properties to set

An alternative to having separate instructions per CP is to have a single
instruction "set configuration parameter" that interprets the beginning of
the line as the name of a CP.
*** Separate instruction, "set"/"let" e.g.
--------------------
[conf]
set home	= ..
set act-home	= ../my-dir
set actor	= --interpreter ...

set status	= SKIP
--------------------
--------------------
[conf]
let home	= ..
let act-home	= ../my-dir
let actor	= --interpreter ...

let status	= SKIP
--------------------
+ the instruction "set" helps to identify these elements as conf params
+ the conf params does not serve as instructions, which may avoid
  confusion by separating instructions and conf params: An instruction is
  something that has a name that is the first element on the line;
  A CP is something that can be set/changes and that determines the
  behaviour of following instructions.
- do not like the imperative/non-declarative style of "set"
  "let" is better. "using" is an alternative, but is maybe associated
  (in other systems) with import of modules and files
** Discusion
Maybe 
* removal of SDS: does it work if there is a read-only file?
<2017-11-13 Mon>
Do not know how read-only files are handled.
Make sure that Excatly does not crach.
* TODO [#C] DestinationPathFromRelRootResolver: Should be Path or PurePath?
Returns type is invalid, but works: combining Path and PurePath in apparently
incorrect way.
* TODO Handling of relative paths
Many paths to resources and sut:s are needed by a test.
Currently (2017-02-26) there is no good way to handle these within Exactly
itself.
Currently this is fixed by a combination of preprocessing and pre-run setup:
 - m4 for preprocessing (for specifying paths in one, and only one, place)
 - autotools for pre-run setup (sets absolute paths to resources)
The current solution
 - requires a lot of knowledge (autotools, m4)
 - fragile and difficult to maintain and debug
 - requires external tools (autotools, m4)

Probably more than one new functionality is needed to handle the problem in an
efficient manner.
** Possibility to have separate "home" for act phase and other phases
The act phase usually need to locate an executable that is references from
many test cases and also test suites located in different directories.
This is different from resources used by other phases - since the other phases
often refers resources that are specific for the test case or the test suite -
and thus can be relative the location of the test case/suite.
** Built in preprocessor
But every preprocessor will have the weakness of handling paths that needs
quoting (even a built in one).  If you only do text search+replace then spaces
,e.g., in paths will cause problems, and will thus require complicated quoting
logic to work.  That kind of logic will make tests much more complicated.

But what a built in preprocessor could help with is the functionallity to
support knowledge of current-source file, so that references can be relative
an included source file, e.g.

For example:
--------------------
[setup]

env set --registered-path GLOB_R_DIR_VAR = GLOBAL_RESOURCE_DIR
env set --registered-path --shell-quoted GLOB_R_DIR_VAR = GLOBAL_RESOURCE_DIR

[act]

my-sut --icons @[GLOBAL_ICONS_DIR]@
/
my-sut --icons @[GLOBAL_ICONS_DIR]@/the-icon.gif

[assert]

contents --rel GLOBAL_RESOURCE_DIR equals icon/x actal/x

run my-assertion-prog @[GLOBAL_RESOURCE_DIR]@
run my-assertion-prog @[GLOBAL_ICONS_DIR]@/the-icon.gif
--------------------

Some kind of syntax for giving registered paths as arguments to programs is
probably needed.  Above @<GLOBAL_RESOURCE_DIR>@ is special syntax for that.

If Exactly had a preprocessor with file inclusion, then paths could be
relative the location of the file the instruction appears in.
(that would need new instruction-information to be available during
instruction execution: the path of the file that contains the instruction.)

*** Validation of references to registered paths
It would be very nice if the validation step could check references to
registered paths.
If every instruction could tell which references it uses and which paths it
sets, then it's possible to do validation-time checking of references.

** env should be able to assign paths using --rel SYMBOL-DEF

env path MY_DIR_VAR = --rel-act act/sub/dir
env path MY_DIR_VAR = --rel DIR_VAL sub/dir
env path MY_DIR_VAR = @{DIR_VAL}@

* TODO Preprocessor process should maybe have timeout
<2016-11-27 sön>
* TODO Act phase
** TODO Name of act-phase actor for error messages
Since the actor (of the act phase) is configurable, it would be informative to the user
to see which actor reports errors.
** TODO single_command_setup : validation_pre_eds should check existence of command
... relative home_dir

Currently, it is reported as an hard error in execute.
* TODO Suite
** TODO Set test case config that serves as default for each test case
Possibility to use all instructions in [conf] for test cases
All instructions in [conf] for test cases should be possible to use
in [conf] for test suites.
The config set by these instructions should serve as the default conf
for each test case (directly) in the test suite.
** TODO Set setup/cleanup to use for each test case
All instructions in [setup]/ [cleanup] of test cases should be possible to use
in a new section [case-setup]/ [case-cleanup]
This setup should be prepended to the setup/cleanup of test cases in the suite
** TODO Set setup and cleanup to execute once before/after the test cases
in the suite are executed.
* TODO Fel (sh, svh, ...) ska representera fel i form av FailureDetails
Har gjort FailureDetails till util-klass.
Den ger möjl till utförligare felinformation än dagens sh, svh
som enbart innehåller en sträng.

I många fall vore det bra att ha både text och Exception.
Ett ex är ActSourceExecutor#prepare() - vid IO-fel vill användaren
veta både Exceptionet och sammanhanget det inträffade i.
(Ev borde ramverket propagera själva steget ut till användaren,
så att den infon inte behöver finnas i form av explicit felmeddelande.)

Har infört FailureDetails i ExitCodeOrHardError.
Se den.
* TODO Finns inget PhaseStep för ActSourceExecutor#prepare
och alltså kollas inte om den körs eller ej.

Se ActSourceExecutorWrapperThatRecordsSteps:
Den spelar inte in ngt för prepare.

O känns naturligt att HARD_ERROR kan inträffa även i prepare.
Så dess signatur bör ändras till att tillåta det.
O detta ska naturligtvis testas.
* TODO ExecutableFileInstruction ska kunna hantera quotade filnamn
Har visat sig lite svårt att testa m nuvarande uppsättning.
Behöver få till det här, dels för att göra tester enklare
* TODO assert/type: Bestäm beteende för sym-link t icke-existerande fil
O dokumentera i hjälptext.
* TODO Gör "actor" till en "configuration parameter"
<2016-05-05 tor>
Lägg till instruktion ("actor") till "conf" för att sätt actor.

Gör ACTOR_CONCEPT till en conf-param.
* TODO Test som inte skrivits: target-renderare för html
* TODO Dok README/wiki
Faser m instrukioner.
Instruktioner härmar unix-kommandon m argument o växlar.

Instr använder en deklarativ stil (namn o syntax).
* TODO Nytt tc-exempel med skräddarsydd test av stdout/stderr/fil
Verkar vara många befintliga shellcheck-likn verktyg som hanterar sånt, så
känns vettigt att ha med ett här.
T ex koll av att filens innehåll följer given syntax/grammatik?
Blir troligtvis behandling m externt program.

Ev är det vettigt att bygga in funk för detta, nån form av reg-ex hantering.
* TODO Se över namngivning av paket (singluaris/pluralis)
"program_modes"
"phase"
"phases"
* TODO Se till att tester inte körs två ggr
T ex TestFinalResultFormatting körs nu två ggr
(en gång m intern MainProgramRunner, eng gång m extern), trots att det inte
använder någon MainProgramRunner.
Orsaken är att det enbart finns en suite(), som används både för att
sammanställa enhetstester och tester mot MainProgramRunner.
* TODO Namnge "genererade tester" mha 'shortDescription'
Se exactly_lib_test.test_resources.main_program.main_program_check_base.TestForSetupWithoutPreprocessor#shortDescription:
----------------------------------------
    def shortDescription(self):
        return str(type(self))
----------------------------------------
Den ger den konkreta testklassens namn som test-namn.
* TODO Exempel
** TODO Ska de levereras m installation?
** TODO Makefile
som skapar/rensar exekverbara, kör svit.
* TODO Installation och distribution
** TODO Distribuera filer
*** TODO LICENCE
*** TODO README
** TODO Ska exemplen distribureras?
** TODO licensfiler
Vet inte vilka licensfiler som behövs, var de ska ligga, vad de ska innehålla,
vad README ska innehålla.
* TODO TypeError ist för ValueError för visitorer appl på felaktigt objekt
* TODO Ändra --rel-cwd -> --rel-cd
<2016-04-03 sön>
* TODO Dokumentation
** TODO Hjälptext för "home directory" "TODO (improve description!)"
** TODO Hjälptext för "cd" "TODO"
** TODO Konsekvensifiera begrepp för assertion ("Tests/checks if ...")
<2016-05-12 tor>
type, exitcode anv "Tests ...".
Har inte riktigt koll på vilka begrepp som översikten använder.
Ev ä "check" bättre iom att "test" benämner testet som helhet.
Eg är "assertion" bäst iom att fasen är assert o assert är det begrepp
som används i testramverk (Assert.assertEqual ...)

Ev bryta ut beskrivnings-strängen för instr-doc t variabel för att
konsekvensifiera beskrivningarna:
("Asserts that ").
(Skulle behöva gå igenom beskrivningarna för det.
Både en-rads-beskrivningarna o användningen i bekrivningar.)
** TODO Enkla test-falls-exemplen ska ha med [setup]
Både i inbyggd hjälp o i README.md
Typ
----------------------------
[setup]

stdin test-telephone-book.txt

[act]

my-telephone-book --get city --for-name 'Per Karlsson'

[assert]

exitcode 0

stdout <<EOF
Vetlanda
EOF
----------------------------

** TODO "Konsistensera" punkt på slutet av single-line-descr ja/nej
<2016-05-09 mån>
Kan inte bestämma hur ja vill ah det.
Så nu finns båda varianterna.
** TODO Test case overview: Förbättra "intro-raden"
Idag
----------------------------------------
Test Case Overview

Executes a program in a temporary sandbox directory and checks it's result.
----------------------------------------
** TODO Sortera "see also" på något lämpligt vis
Ev automatisk sortering, men ä inte säker på att det finns något enkelt
vettigt att tillgå att anv som sorteringsvärde.
** TODO Byt ut "action to check" mot "system under test"
action to check reffar visserligen till [act], men
SUT ä den vedertagna benämningen.  O tror kan göra pgm mer lättillgängligt om
den används.
** TODO Dok på nätet: använd begrepp som används av likn pgm (googla!)
... så att excactly hittas då man gör en likn sökning.

"test command line application" dök upp som förslag nä ja googlade fr mobilen.
** TODO Fas: fas-följd: nämna att faser hoppas över om fel inträffar
Enda faserna som garranterat körs är conf/setup o cleanup.
** TODO Koncept "environment variable"
Lista env-vars o när de sätts.
** TODO Förbättra koncept "home directory"
** TODO Dok tanken att instr tar arg pss som unix-kommandon m växlar
Det här är ju en genomgående tanke.  Som sådan bör den dokumenteras/nämnas.
Samt att unix-skal syntax används för quotning.
** TODO Programmets namn ska "konfas" i ApplicationHelp
** TODO Users Guide
** TODO I avsnitt om att [act] ä utgångsfas: exempel /bin/rm -rf *
** TODO html doc
*** TODO Ska in i ApplictionHelp: program -namn & -version
De ska inte behöva härledas via globala saker.
----------
PAGE_TITLE = '%s Reference Manual' % program_info.PROGRAM_NAME
version.text = program_info.PROGRAM_NAME + ' version ' + program_info.VERSION
----------

*** TODO _application_help_with_phases
Saknar concepts_help arg till ApplicationHelp.

*** TODO htmldoc ska vara nytt program-mode
Nu genereras html via help htmldoc. Det kommandot borde ge _hjälp_ om html-rendering - inte
utför själva renderingen.

Har påbörjat det här. Men i cli-paketet är det fortfarnde en form av hjälp.
Fortsätt m att införa ny funktion i MainProgram.

*** TODO hjälpkommandot ska ha egen metod i MainProgram
I dag är det en specialare som inte invokerar en medlemsmetod pss som "test-case", "test-suite".

exactly_lib.cli.main_program.MainProgram#_parse_and_execute_help

** TODO Resten av dok (faser, svit)
** TODO formatteraren ska inte bryta rad i --preprocessor
<2016-03-28 mån>
Den tolkar det som binestreck mellan ord och bryter rad.  Behöver stänga av
den funktionen.
** TODO parse == syntax?? Felkod 'PARSE' men steget heter "syntax check"
I dok "test case processing" listas faserna.
En av dem är "syntax checking", och den är vad som internt kallas "parse".
Felkoden från denna är "PARSE", vilket rimmar illa m "syntax checking".
Vore nog bättre m "SYNTAX" alt "SYNTAX_ERROR"
** TODO instr ge getter av InstructionDocumentation istf obj direkt
<2016-04-02 lör>
Prestanda.  Vill undvika importer för hjälp under normal körning.
Det blir svårt när ett objekt ges direkt.
Se InstrDescr för "mode", som måste importera samma paket lokalt två ggr.
** TODO Dokumentera syntax för flerrads-instr i InstrDoc
<2016-03-22 tis>
Tror inte dok nämner syntax för fler-raders instr.
Får klura på hur det dokumenteras enklast.

** TODO [#A] Förtydliga att sidoeffekts-instr (dir) under "assert"
<2016-03-20 sön>
Eric undrade vad "dir" gjorde i "assert"-fasen.

Det behöver förtydligas att de finns där först o främst för sidoeffekternas
skull - att de fungerar mer som hjälpmedel än som assertions.
(Hur fungerar det egentligen?? Om dir misslyckas, antar att det blir
HARD_ERROR då. Men är inte 100!!! Behöver förtydligas.)

* TODO Meningsfullat att validering kan ge HARD_ERROR?
<2016-03-28 mån>
Tror inte nån instr's validering avnänder HARD_ERROR.  Ty det är ju liksom
valideringens uppgift att upptäcka sådant som skulle orsaka HARD_ERROR om det
kördes, väll??
HARD_ERROR bygger ju på att det upptäcks!  Sånt som inte upptäcks blir ju
implementationsfel!
* TODO Exitkod vid fel
<2016-03-28 mån>
FÖr CLI-parsning avslutar ArgumentParser m 2.

Det är densamma som sc använder för FAIL.

Samtidigt använder sc 3 för att indikera att testet inte exekverats (pga
VALIDATE, PREPROCESS ...).  Ligger det inte mer i linje att den koden är
densamma som för felaktig CLI-syntax?  I båda fallen så har ju inget test körts.

Dock så skiljer sig fel från CLI-syntax/fil-ref från andra fel i och med att
det i det förra fallet inte skrivs ut någon felkods-identifierare (PASS, FAIL,
VALIDATION, PREPROCESSING ...).

Ta reda på vilken fel kod som ges då programmet avslutas pga ohanterat
undantag.  Se till att ligga i synk m det felet (borde vara samma exitkod som
IMPLEMENTATION_ERROR, om möjl).

Vore vettigt att inte försöka ändra exitkoden som python använder vid
obehandlade undantag eftersom det ju alltid kan uppstå undantag innan den
koden ändrats.

* TODO Optimera gnm att importera valfria moduler lokalt
<2016-03-21 mån>
Moduler ska laddas vid behov.  T ex modulen för hjälp ska laddas enbart om
hjälp efterfrågas.
Tror detta ska kunna lösas m lokala importer.

Koden som köra case/suite/help:
exactly_lib.cli.main_program.MainProgram#execute
* TODO <2015-05-03 sön> Nya refaktoreringar
** TODO Nya modulnamn
- document (dok m faser o instr, syntax, parsning)
- test_case (def faser o instr för TC, subklasser t Instruction ...)
- execution (så som det är idag)
* TODO Testfalls layout, namngivning, etc
** TODO Fas-namn i versaler för tydlig separation fas / instruktion
Om faserna måste skrivas m versaler kan ev göra testfallen tydligare.

Alternativt ska fasnamn vara skiftokänsliga.
* TODO Byt namn: Anonymous -> Configuration
* TODO __main__ ska köra run_suite (inte unittest.main())
<2016-01-19 tis>
if __name__ == '__main__':
    unittest.main()
* TODO Skräddarsy act-fasen
** TODO Då interpretator anges via CLA: resolva abs-sökväg till denna
... så att det går att ange relativa sökvägar på kommandoraden (o ev, i en
senare framtid, även i testsviter).
Ev två olika setup: en som resolvar relativa sökvagar, o en som inte gör det.
* TODO Exekvering av fall: Rapportera mha "Rapportör" (pss som svit)
* TODO Kring instruktioner
** TODO PassOrFailOrHardError: FAIL ska kunna ta olika varianter av felmeddelande
- sträng
- förväntat värde, verkligt värde, namn på egenskap
Inför subklass för varje variant.
** TODO assert-instr: Infrastruktur för att hämta vanliga värden
T ex returkod, utdata på stdout/err.
Funk kan antingen
- ligga i ActPhaseInstruction
- objekct åtkomligt via medlemsmetod i ActPhaseInstruction
- objekt som skickas till main

Tror bäst att skicka obj till main.  Då kan infrastrukturen säkerställa att
alla instruktioner får samma objekt.  Därmed kan objektet lagra privat data då
den efterfrågats (prestanda)
* TODO <2016-01-08 fre> Arg till olika Expectation har olika namn
Namnen ska strömlinjeformas.
* TODO <2016-01-08 fre> instr/main har olika ordning på arg (env, os_servc)
Olika hos bl a BeforeAssertPhaseInstruction o AssertPhaseInstruction.
* TODO <2016-01-07 tor> Funderare på exekveringsflödet
** När ska cleanup-instruktionerna köras?
Se separat dok om detta under "cleanup".
* TODO <2016-01-07 tor> Gemensam basklass för instr m std-validering?
Skulle t ex kunna finnas i InstructionWithStdValidation:
 - validate_pre_eds
 - validate_post_setup

En fördel är att det gör det möjligt att "typ-säkert" återanvända
steg-exkeverare (de som partial_execution använder för att köra steg).

* TODO <2016-01-06 ons> execute: La till --rel-act: Ta bort?
Finns en anledning till att jag inte laggt dit den från början?
T ex att det inte ska gå att lägga program i act som ska köras?
Å andra sidan, varför omöjliggöra det istället för att låta det vara upp
till användaren att bestämma var filerna ska ligga?
* TODO cleanup
** TODO Infra-strukt för instr-test: Möjl att ange act-result
<2016-01-07 tor>
För tillfället kan inget resultat för act anges i dess Arrangement.
assert:s Arrangement, t ex, anger alltid ett act-resultat.  Vilket
naturligtvis beror på att act-fasen garranterat körts då assert körs.

För cleanup _kan_ act-fasen ha körts, men det är inte säkert (dvs en cleanup
som körts efter att en setup-instruktion fallerat.)

Det måste finnas möjlighet att i cleanup:s Arrangement ange om act-fasen ska
ha körts, genom att angen en "act-result-produser" pss som för assert.
** TODO cleanup ska ha validate/post-setup?
För vissa instruktioner är den meningsfull - det är oundvikligt att en
validering måste göras innan själva "main-main" kan köras.
T ex för execute: det exekverbara programmet kan inte köras om, t ex,
källkodsfilen existerar.

Skillnaden mot att utföra motsvarande validering i main är att, om det görs i
main, så kan act-fasen låtas skapa nödvändiga filer.

Känns dock rimligt att ha en validering/post-setup även i cleanup.
Det skadar inte.  Någon instruktion borde kunna använda den, om inte annat
skräddarsydda instruktioner.
** TODO Ska alla instruktioner köras, oavsett om någon misslyckas?
cleanup-instruktionerna skiljer sig ju åt i syfte.
Även om en upprensnings-instruktion misslyckas så kan det vara önskvärt att
köra efterföljande upprensningar, eftersom de kan tänkas rensa upp olika
resurser.  Och ju mer som renasa dessto bättre, helt enkelt.
Eller?
En variant då det inte är önskvärt är då en instruktion används för att ta
redapå hur mycket som act-fasen lyckats åstadkomma.  Det kan ju vara så att
vissa upprensningar inte ska köras såvida inte act-fasen gjort vissa saker.
Om act-fasen misslyckas vill man alltså inte utföra vissa upprensningar.
I sådana fall kan en instruktion användas för att avbryta upprensningen.

Ett alt är att införa möjligheten att villkora exekveringen av instruktioner.
T ex
--------------------
if CONDITION {
INSTRUCTION-LIST
}
--------------------

o kanske är det användbart att kunna välja att avbryta exekveringen:

--------------------
break
--------------------

Kanske vill man ange i konfigurations-fasen om cleanup-fasen ska avbrytas
eller fortsätta vid instruktions-fel.

Om cleanup-fasen fortsätter exekvering efter instruktions-fel så behövs
antagligen något sätt att välj att avbryta den vid utvalda instruktions-fel.
T ex
--------------------
break-on-failure {
INSTRUCTION-LIST
}
--------------------

alt

--------------------
@break-on-failure INSTRUCTION
--------------------

** TODO <2016-01-06 ons> olika main beroende på om act körts el ej
Olika metoder hos en cleanup-instruktion ska anropas beroende på om act-fasen
exekverats eller ej.  Dvs en cleanup-instruktion ska vara medveten om i vilket
läge den anropas.

Alternativt skickas en flagga till main-metoden som anger "läget".
Detta kan vara en bättre lösning eftersom det är enkelt att utvidga m fler
"lägen".
Denna lösning gör det t ex möjligt att tala om exakt vilken fas som kördes
innan cleanup-anropades:
 - SETUP
 - BEFORE-ASSERT
 - ASSERT

Osäker på hur användbart det här verkligen är för stora merparten av de
vanliga instruktionerna.  Har tänkt på det och tror inte det är speciellt
användbart.
Men känner ändå att det vore bra att implementera det för att ha en
infrastruktur som inte är begränsande - om nu behovet skulle uppstå i en ev
avlägsen framtid.

Mest användbart är det antagligen för skräddarsydda instruktioner, kanske
tillsammans med en skräddarsydd act-fas-exekverare.
Dvs mest användbart är det kanske då programmet används i ett mycket specifikt
sammanhang, kanske ett sammanhang där alla instruktioner och exekvering är
skräddarsydd.  I ett sådant fall fungerar programmet mer som
infrastruktur. Och det är ju attraktivt om det kan användas även i det
sammanhanget!
* TODO Expectation: använda samma namn för konstruktor-argument
Använda samma namn i alla varianter av Expectation (dvs för de olika faserna).
Nu finns t ex
 - validate_pre_eds_result
 - validation_pre_eds
* TODO Paketstruktur: ev lägga instructions o act_phase_setups i gemensamt pkt
<2016-01-13 ons>
Lägg i ett paket som enbart innehåller "utdvidningar".
Dvs separera
 - infrastruktur
 - användning av infrastrukturen
* TODO main-program: möjl att köra flera tester m en o samma kommandorad
Typ: Om fler än en tesfalls-fil anges så körs de som en test-svit.

En temporär testsvit skapas bakom kulisserna.
* TODO Python-saker
** TODO Är klasser py3? Ska det vara MyClass(object)?
Ev ska varje klass explicit ärva object för att vara en py-3-klass.
* TODO tmp-filer för instruktioner
Bör införa hjälpfunktion för att skapa tmp-filer för instruktioner.
Nu: contents/stdout/stderr: Ser själva till att lägga tmp-fil i
tmp/internal.
Vill ha funktion, typ: tmp_file_for_instruction(prefix,suffix,contents)
-> pathlib.Path
som automatiskt lägger den i tmp/internal.
* TODO Syntax för instruktioner: vänta till EXPECTED ACTUAL??
Bör se på om det är möjligt.
T ex
5 exitcode
empty stdout
empty file.txt
contents --rel-home expected stderr
type directory my-file

Känns faktiskt aningen konstigt.  Spec exitcode. O även empty.
* TODO Alias för instruktioner
Kan behövas för att attrahera utvecklare med olika bakgrund.
Speciellt
 - "pwd" kan behöva heta "cd"
 - "dir" kan behöva heta "mkdir"
Dock, ett alt är naturligtvis att skapa alias m makron.  Är nog det enklaste,
trots allt, iom att det förenklar programmets struktur, och funktionalliteten
oavsett kommer att finnas iom makroprocessor.
* TODO Tester som inte är skrivna
** TODO Preprocessor med mellanslag
Utmaningen är att själva exekverbara preprocessorna kan innehålla mellanslag o därför inte får splittas,
samtidigt som det ska gå att ge argument till den som ska splittas.
T ex
 Själva preprocessorn: "c:\prog files\python.exe"
 Argument: "-c", "<något>"
Ett alt är att ge exe o arg m separata växlar.
Samtidigt är det bekvämt att kunna ge preprocessorn i en enda växel.
** TODO content/stdout/stderr --with-replaced-env-vars körd > 1 gång
Eftersom befintliga transformerade filer återanvänds är beteendet annorlunda
för användning nr > 1, än första gången. Måste alltså testas.
Metod: Ev köra helt testfall o helt enkelt använda samma instruktion två
gånger.
** TODO default main program: kolla att faserna innehåller rätt instruktioner
----------
Scenario:
Alla tester passerades
men gick inte att köra programmet pga att instruktionsuppsättningen var fel.
Instruktionerna för fasX låg i fasY, typ.
Felet var felaktig sekvens av argumenten till InstructionsSetup i
exactly_lib/default/execution_mode/test_case/default_instructions_setup.py
----------

Lösning, typ: test som kör testfall m en "unik" instruktion från varje fas.
("unik" = instruktion som inte finns i någon annan fas.)
* TODO Misc
** TODO <2015-01-05 mån> abs_syn_gen.TestCase instances must be valid
The constructor should validate all arguments
The list of phases must:
- be ordered according to phase execution order
- type of environment must be correct for each phase

** DONE <2015-01-05 mån> May be StatementsGeneratorForInstruction should not be given ScriptLanguage
... since each StatementsGeneratorForInstruction is probably not designed to
handle an arbitrary language.
Giving a ScriptLanguage to apply, indicates that it should be capable of
handling arbitrary languages.

** TODO <2015-09-25 fre> EDS: test-root ska heta "act"
Mkt enklare att koppla ihop med fasen "act".

** TODO Ska omgivningsvariablerna ha ett "_DIR" på slutet?
Känns vettigt.  Tydligare, helt enkelt.
O tror innehållet i filer där omgivningsvariablerna bytits ut blir tydligare:
Utan _DIR:
----------------------------------------
EXACTLY_ACT/data/dir/existing-file.txt
----------------------------------------
med _DIR:
----------------------------------------
EXACTLY_ACT_DIR/data/dir/existing-file.txt
----------------------------------------
Det blir helt enkelt tydligt att man pratar kataloger.

** TODO --rel-tmp : i assert-fasen ska det ange fil relativt tmp/
t ex
contents --rel-tmp transformed-stdout.txt --rel-home expected-contents.txt

** TODO <2016-01-06 ons> PHASE_phase_instruction_that: action ska ta alla arg
De steg-metoder som tar flera argument ska ha en action som tar alla dessa
argument i en tupel.
I dagsläget gör en av stegens action det (minns inte vilken), medan andra inte
gör det.  Den olikheten är bara dålig.
* TODO Miljövariabler
** TODO EXACTLY_HOME ska ev inte vara tillgänglig i [act]
<2016-04-02 lör>
Det riskerar ju att atc (action to check) kan sabba
filer där.
** TODO Instruktioner: os.path.expandvars för att expandera miljövariabler
Finns även en
os.path.expanduser
för att expanera ~user.
* TODO Kommandorads-program
** TODO Hjälpsystem via CLI
Förslag:
*** -h | --help : Elementär hjälp. Hjälp för hur använda kommandot "help"
*** Kommando "help" : om skrivs som första argument på CL
**** Enbart "help" : hjälp om hur använda "help"
**** help phase : Översikt över faserna
I vilken ordning de körs och deras inbördes roller.
**** help phase PHASE : Detaljerad info om fasen PHASE
**** help instruction : Översiktlig hjälp om instruktioner
**** help instruction INSTRUCTION : Detaljerad info om instr INSTRUCTION
** TODO Funktion för att köra assert/execute på given EDS
För felsökning av assert.
Tänkt användning:
1. Kör hela snurran (ev utom cleanup), och spara EDS.
   Troligtvis ger assert ett oväntat resultat som behöver felsökas.
2. Mixtra med innehållet i EDS.
3. Kör assert/execute på given EDS.
4. Upprepa 2-3 tills assert ger förväntat resultat.
5. Rätta till felet (i SUT, setup, act, el assert).
6. Radera EDS manuellt, eller kör exactly m växel som enbart kör cleanup,
   inklusive automatisk radering av EDS.  Kör denna mot angiven EDS.
** TODO Dok för enskild instr ska ges av funktion
Optimering: För att undvika att programmet alltid lägger tid på att ta fram
dokumentation.
Oftast kommer programmet att köras för att utföra ett testfall/svit, och
prioriteringen är att få det att gå hyfsat fort.
* TODO Formgivning av instruktionsuppsättning
** Anonyma fasen: Fixerad mängd instruktioner
Icke konfigurerbar pss som övriga faser, iom att denna fas har en speciell
uppgift att styra kommande faser.
** Instr har antingen arg enl argparse, eller skräddarsydd parsning
Skräddarsydd parsning funkar bäst för t ex instr i act-fasen som enbart är
källkod som ska kopieras till skriptet.
** Generella instr: Instr som kan köras i alla namngivna faser
Borde gå/finnas behov av att skriva generella instruktioner som kan köras i
vilken som helst av de namngivna faserna, eller kanske snarare, i vilken som
helst av faserna som har tillgång till EDS.
*** Ta fram SGD för dessa instruktioner (t ex EDS + HOME)
Ev är problemet här fasen "setup", vars "validate" inte har tillgång till EDS.
Kanske är det av den orsaken värt att skapa EDS innan setup/validate.
* TODO Göra det enkelt att utöka programmet m egen act-phase-setup
<2015-10-05 mån>
Osäker på hur användbart det är att ha olika act-phase-setup.  Men vore hur
som helst en "skyddande felxibilitet" om det vore enkelt (dvs på något sätt
förberett så att det inte krockar med något).
* TODO Specifika instruktioner
** TODO Se över instruktionsnamn
Har nu valt att använda deklarativa namn.
Tex
 - workdir (ist f cd)
 - dir     (ist f mkdir)
 - file

Är detta bra?
Tycker det ökar läsbarheten.
Dock kan vara motiverat att använda inarbetade/standardiserade namn (som t ex
"cd" och "mkdir").
*** Olika konventioner för olika faser?
Ett alt är att använda olika konventioner för olika faser.  T ex skulle
setup-fasen kunna använda procedurella namn, medan assert-fasen använder
deklarativa.

Tanken har kommit efter att det känts att det kan vara konfunderande att i
setup-fasen ha instruktionen
----------
pwd my-dir
----------
eftersom den ser ut som ett test i assert-fasen: Assert att pwd = my-dir.

De faser som "utför" saker - setup o cleanup - skulle kunna ha procedurella
namn.
** TODO sök+ersätt
Är en vanlig informations-operation.  Är den vanlig i det här sammanhanget?
Vet inte.
Men innebär viss risk att inte ha den.

Vore bra att ha en sök+ersätt för reg-ex.
Vore bra om man kunde använda omgivningsvariablers värden i sök/ersätt
uttrycket.  Hur ska det göras?? Inte enkelt. Måste ha en syntax för att komma
åt dem. O den syntaxen får inte krocka med reg-exen.  Kanske enklast att (till
en början med, i varje fall) använda shell-syntax: ${ABC_abc_123}.
Om en annan syntax ska användas ska det vara en som krockar så lite som
möjligt med reg-ex syntax.
** TODO Sätt systemets TMP-katalog till ${EXACTLY_TMP}
Används antingen i setup eller anonyma fasen.
Eller kanske införa ny katalog under tmp för att separera testfallets
hjälpfiler från sut:ens.
Helt klart vettigast att separera.  Finns ingen bra anledning till att inte
göra det.
Inför t ex tmp/act/.
** TODO Skapa temporär fil (filnamn tas fram automatiskt, läggs i EXACTLY_TMP)
** TODO file
*** TODO Använda syntax mer lik unix "test" och "find"?
Fördel iom att den är välkänd.
** TODO file/stdout/stderr --rel-cwd
*** TODO HARD_ERROR ifall jämförelsefilen inte finns?
Nu ges FAIL: felet betraktas som en form av olikhet.
*** TODO Bättre felmeddelande för stdout/stderr
Nu:
----------------------------------------
Line 68: `stdout    --rel-home output/absolute-file-paths-existing.txt'

Unexpected content in file: /tmp/exactly-290sqrhe/result/std/stdout
----------------------------------------
Det framgår inte tydligt att det handlar om stdout. Man får själv ana det,
genom att leta reda på "stdout".

Även när man använt --with-replaced-env-vars får man exakt samma meddelande.
Det framgår inte någonstans (förutom på källkodsraden) att det handlar om
varianten med variabler utbytta.
** TODO innehåll i fil (contents, stdout, stderr)
*** TODO Visa diff: undvika krash pga för stor fil
Tyvärr verkar diff-beräknaren inte vara lat: den vill ha in båda filerna i
minnet (i form av listor).
Ev behövs möjlighet att begränsa antal bytes som läses in i internminnet.
Möjlighet att sätta max gräns.
Ev även möjlighet att sätta övre gräns på antalet rader i diffen som visas.
Kanske räcker det med att hårdkoda ett max.
** TODO setup/install
*** TODO <2015-11-03 tis> Hantering av multi-path-comp DESTINATION
Idag är beteendet för DESTINATION som innehåller flera path-komponenter
(t ex a/b/c) odefinierat.
*** TODO <2015-11-03 tis> Sök+ersätt i filer som installeras
Har ett testfall för filelist som gör just detta mha ex.
Ersättningsvärdet är absolut sökväg för testets rot (EXACTLY_ACT).
Antar att detta är relativt vanligt.  Därför borde exactly ha en sådan
funktion inbyggd.
** TODO mkdir
*** TODO mkdir --rel-tmp DIRECTORY
Skapar katalog under tmp/user.
** TODO interpret/execute/source
*** TODO Validering: att filen är exekverbar
Använd stat.S_IXUSR
Den kollar om filen är exekverbar för användaren.
Men ä osäker på om den enbart kollar om exekverings-flaggan är satt för
användaren.  Det räcker ju inte.  Ty den kan vara satt för gruppen, o aktuell
användare är medlem i gruppen som äger filen.
* TODO Faser
** TODO Act
*** TODO <2015-09-26 lör> Parser ska ha syntax för att inkl [abc]-rader i källkoden
Dessa rader är ju sektionsrubriker, och är därför omöjliga att inkludera i
källkod.  Parsern ska ha syntax som löser detta.
Förslag:
"[abc]"		: vanlig sektionsrubrik
"\[abc]"	: källkod: "[abc]"
"\\[abc]"	: källkod: "\[abc]"
"\\\[abc]"	: källkod: "\\[abc]"
Det är alltså enbart första o ev andra tecknet som hanteras speciellt.
Därefter är allt som vanligt.
* TODO Förbättringar
** TODO Variant "<<EOF ...\EOF": sista raden avslutas ej m nyrad
Enda begränsningen hos "<<EOF...EOF" är ju att sista raden måste avslutas m
nyradstecken.  Det är naturligtvis en begränsning.
Undrar hur skalen gör där, föresten.  Kanske har de en motsvarande syntax.
** TODO <2015-05-17 sön> Bevara glob tillstånd
Idag sparas omgivningsvariabler "runt" partiell exekvering.  Borde sparas runt
"full" exekvering, naturligtvis.
Vore bäst (känns nu) om hela exekveringen kunde ske i sub-process.
(se modul concurrent.futures)
* TODO Härleda interpretator
bash, sh, csh ...???
Går det att ta reda på ett utgångsvärde för interpretator för varje plattform
(dvs via python)?  El måste den anges explicit?
* TODO Testa på andra plattformar (Windows, Mac)
Ev måste hanteringen av ny-rader justeras.
python har ju något som heter "universal newlines".  Ev ska det användas (om
det inte redan används idag!)
* TODO Svit
** TODO Hjälp-funktionallitet för svit-kommandot
** TODO Svit: Reffa flera fall-filer mha jokertecken
Typ:
[cases]
sub-dir/*.case

** TODO Gruppering av testfall
Ev ange i varje enskilt testfall:
groups database groupX groupY

Ev ange i svit-filerna.  På sätt o vis är det ju enbart i svit-filerna grupper
är relevanta iom att det enbart där är meningsfullt att arbeta med grupper av
fall.
Skulle kunna ha instruktion "@groups" i svit-filer (mycket liknande hur
filelist använder @tags).
** TODO Köra enskilda testfall i sub-process
** TODO <2015-07-14 tis> Rapportering: Borde inte rappoteringen vara rekursiv?
Nu (djupet-först):
----------------------------------------
sub-suite: BEGIN
sub-case: PASS
sub-suite: END

main-suite: BEGIN
main-case: PASS
main-suite: END
----------------------------------------
Borde det inte vara:
----------------------------------------
main-suite: BEGIN

sub-suite: BEGIN
sub-case: PASS
sub-suite: END

main-case: PASS
main-suite: END
----------------------------------------

Dagens impl har fördelningen att en svits BEGIN o END inkapslar "direkt"
svitens egna testfall.
Nackdelen är att det inte går att spåra inklusions-hierarkin.
Frågan är vad som är vettigast.  Borde kolla på hur andra gör o följa det
vanliga sättet.
(Makefiler kör enl icke-nuvarande.  Å andra sidan har man inget val där, iom
att det handlar om att "överliggande" moduler är beroende av "underliggande".
El, jo, i rapporteringen har man naturligtvis ett val!  Dock inte i själva
beräkningsordningen.)
** TODO <2015-09-26 lör> Miljövariabler - köra varje tc i separat process
Miljövariabler medför problem för test-sviter, iom att de är globala, o därmed
ändrar förutsättningarna för efterföljande test.
Egentligen är det enda vettiga att köra varje test i en separat process.
Då kan instruktioner i [setup] sätta miljövariabler.
Det finns en fuktion os.fork, men denna är enbart tillgänglig i Unix.
Ev behöver det införas ett nytt koncept: SubProcessTestCaseExecutor, som
exekverar ett testfall i en sub-process.  Denna kan behöva implementeras olika
för unix/övrigt.

Har för mig att i dagsläget så sparar+återställer full_execution alla
miljövariabler.  Det ska den inte behöva göra.  Speciellt när ett enda
test-fall körs är det helt onödigt eftersom exactly kör i en separat
process, vars sidoeffekter i form av miljövariabler försvinner när det
avslutas.

Ett alternativ är att låta det exekverbara programmet sätta dem.  Men då
förändrar man SUT, vilket inte alls är bra.

Ytterligare ett alternativ är att
 1. Låta instruktioner förändra miljövariabler indirekt genom att lägga
    ändringarna i en lista.
 2. Låta ett program som kör precis innan SUT, ändra de faktiska variablerna i
    enlighet med denna lista och sedan köra SUT som en sub-process.

Detta är dock krångligt!!

* TODO Loggning
* TODO Blandat
** TODO <2015-09-26 lör> Funktioner för att läsa act-resultat
Ska finnas hjälpfunktioner i "biblioteket" för att läsa t ex statuskod på
korrekt sätt - dvs kasta rätt undantag om något går snett.
Idag läser t ex instruktionen "exitcode" själv exitkoden. Det ska den inte
behöva göra.
** TODO Instr-namn-parser: "_" ska kunna ingå i instruktionsnamn
* TODO Prestanda
** TODO All dokumentation ska skapas vid behov
Dvs ska inte finnas konstater på global nivå.
Ska istället finnas funktioner på global nivå:
def get_document() -> Description:
  return Description(...)

* TODO Refaktoreringar
** TODO Rendering
*** TODO Extrahera test av textrenderare till eget test
Idag är del av test av paragraph.

*** ParagraphItemRenderer för test ska kunna rendera riktiga Para[StrText]
Idag enbart konstant värde.
Om en renderare av endat ett enda fall men som renderar riktig data så
förbättras testerna genom att verifiera att rätt element renderas.

*** TODO Test av FullParagraphItemRenderer
** TODO Modulorganisation
*** TODO script_language
SourceInterpreterSetup
Bör kunna tas bort.
Är enb en wrapper av SourceFileManager
*** TODO instructions, act_phase_setups
Var ska de ligga!!!???
De har det gemensamt att de tillhör test-case och att de är "utvidningsbar"
funktionallitet.  Vill inte ha dem på högsta nivå.
*** TODO document -> section_document
** TODO Refakt: full/partiell exekvering i separata paket
<2016-04-02 lör>
** TODO Bör ersättas med funktionerna i python_program_execution?
Tror det är precis det här de funktionerna används till.
----------
    def file_structure(self, root_path: pathlib.Path,
                       python_executable_file_name: str,
                       preprocessor_source_file_name: str) -> DirContents:
        preprocessor = '%s %s' % (quoting.file_name(python_executable_file_name),
                                  quoting.file_name(preprocessor_source_file_name))
----------
** TODO Validate_post_eds_if_applicable ska ta (EDS,home_dir)
<2016-01-09 lör>
klass: PreOrPostEdsSvhValidationErrorValidator

I nuläget tas enbart EDS.
Onödigt att begränsa till att ta enbart EDS.
Skulle ju kunna finnas en instruktion som använder både EDS och home_dir.

** TODO Byt till ValueAssertion där det går
*** TODO instruction_checks
*** TODO text-structure tests
** TODO Extrahera gemensam kod för Expectation
<2016-01-09 lör>
*** TODO Extrahera basklasser
*** TODO config
*** TODO setup
*** TODO assert
*** TODO cleanup
** TODO <2016-01-06 ons> Byt namn: Anonymous -> Config
** TODO <2016-01-06 ons> Byt namn: GlobalEnvironmentForX -> EnvironmentForX
Gäller typerna för arg till instruktionernas steg-metoder.
** TODO Göra sig av med fel-typen som är överflödig (fr UML, Failure?)
** TODO Argument till instruktionernas steg
Spikade först två generella miljöer: global miljö och fas-miljö.
Iom att den modellen inte längre används kan mer ändamålsenliga argument
användas.
*** TODO act/script-gen
Två argument:
1. Skriptbyggare
2. Inställningssättare (för t ex stdin).
** TODO Använda nya TestCaseSetup i äldre tester
Som du finns flera instruktions-klasser som enbart returnerar ett visst värde
eller kastar undantag.  Alla de fallen kan hanteras av nya TestCaseSetup.
* TODO Finputs
** TODO Tidtagning för testfall i svit
Liknande den för hela sviten.
** TODO <2015-05-18 mån> Ev skapa EDS senare
Enl diagram ska den skapas precis efter setup/validate.
Idag skapas den precis innan setup/validate.
Ingen stor grej, men kan ev ändras.
Alternativ ändrar man spec till att göra som idag.
* TODO Ny funktionallitet
* TODO Förbättrin av instr
** TODO dir: möjl att ange path rel annat än pwd (mha --rel...)
** TODO install: möjl att ange path rel annat än pwd (mha --rel...)
** TODO Ny växel "--rel-res" för reffa filer i sandbox/result
<2016-05-01 sön>
** TODO Integration m perls TAP (Test Anything Protocol)
<2016-05-01 sön>
Om möjligt att anvnda programmet fr TAP skulle det troligtvis bli mer
användbart.
** TODO Testa ange preprocessor för TF via kommandoraden
** TODO Inbyggd preprocessor
Vore bäst om programmet innehöll en egen preprocessor.
På så vis maximeras oberoende av yttre miljön.
Funktionallitet:
- filinklusion
- definitioner av konstanter
- definitioner av funktioner
Har tittat på:
*** PYM (mest lovande)
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.400
Men hittar inte källkoden för den här.
*** Pythons inbyggda stängformattering (format())
file:///usr/share/doc/python3.4/html/library/string.html#string-formatting
Kanske är denna tillräckligt kraftfull för att fungera som preprocessor.
Dock förutom filinkludering, förutsätter jag.
** TODO Köra flera tester på CL som "anonym" svit
** TODO Färgläggning av exit-identifierare
OK grön, FAIL röd ...
VALIDATE ... orange
** TODO <2015-05-22 fre> Konfbar gemensam miljö för alla instruktioner
Införa argument som ges till alla metoder i alla instruktioner.
Skulle erbjuda mölighet att skräddarsy den information som instruktionerna har
tillgång till.


