Rewrite TUI als workflow incl. State en Unit Tests

[chrispijo]

TODO: Waarom doen we dit nou. Om in de toekomst de TUI makkelijker te beheren.

Verkenning om het de Terminal User Interface als workflow van Question- en Action-objecten (parent: Step) te schrijven waarbij het afhangt van de State of een Step object daadwerkelijk wordt uitgevoerd. Enkele voordelen:

• TUI is als workflow volledig te doorlopen in een unit test.
  Op dit moment gebeurt dit met random keuzes voor de Question-objecten.
• Unit test kan de logica van de Step-objecten eenvoudig aanroepen. Dit maakt het veel minder abstract en ook voor een minder ervaren programmeur te volgen.
• De eerdere suggestie van Vincent met State maakt het eenvoudig om te controleren of een Step uitgevoerd moet worden. Dit is inclusief dat de data in de DB definitief is.

Momenteel ben ik het idee nog aan het verder verkennen, voordat het ik het voorstel. De de logica uit de huidige TUI moet namelijk wel omgezet worden naar deze nieuwe versie.

PR aangemaakt voor inzicht in coverage.

[chrispijo]

De coverage is echt significant goed:

[chrispijo]

Indien doorvoeren:

• Kijk ook even naar de warnings (allemaal deprecations warnings) in de unit test.

[chrispijo]

Ook nog verkennen:

• Hoeveel tijd kost de workflow (systeem) test.
  Tijd bijhouden in pytest commando.
• De random.choice() is tricky als workflow (systeem) test.
  Hoeveel tijd kost het om alle mogelijke paden te testen?
• Is het mogelijk dit geleidelijk te implementeren?

[VincentJilesen]

Ik heb al een keer goed doorgelezen en hierbij alvast mijn twee centen:

De standaardisering van de stappen van de TUI is zeker netjes en helpt het ook beter gestructureerd te houden. Het State() object zorgt ervoor dat de in- en output van de gpkg nu overal simpel te vinden en gebruiken is. Ik zag ook nette upserts in de QuestionAnswer. Dit moet misschien ook in de GeoDataFrames en DataFrames als je ze niet altijd geheel wil overschrijven. Dit is meer iets voor de toekomst maar als je nu toch ermee bezig bent.

Het testen is me nog wat onduidelijk. Deels omdat ik na het bestuderen van unittests me afvroeg of de systeem test automatiseren noodzakelijk is. Misschien is dit juist iets om handmatig te draaien tijdens het maken van de commits.

Ik zag dat je aanliep tegen verschillende bestands paden tussen de losse tests en de github tests. Deze kan je oplossen door een fixture te maken van het testbestand en dat in je test in te voegen als argument. Je kan pytest zelf een database laten opzetten in tmp_path met de geopackage.

Daarnaast zag ik dat je ergens random choices invoerde. Voor een unittest is het juist belangrijk dat alle mogelijke paden door een functie altijd getest worden. Dit is ook waarom ik nu twijfel aan de meerwaarde van een automatische systeem test omdat je dan alleen de correcte paden test maar niet de mogelijke errors.

Je had alle losse test geschreven voor een paar van de stappen. Je test voor de hrd database wel of er iets wordt ingevoerd en of alle punten zijn ingevoerd maar niet of deze rijen ook inhoudelijk kloppen. En voor de Questions wordt niet getest of de output van de Inquirerer wel correct wordt verwerkt.

[chrispijo]

Ik zat gisteravond nog te denken dat dit idee het ook mogelijk maakt om 'terug te gaan vorige vragen'. Rekening houdend met:

• Ga je terug, dan is het eerder gekozen antwoord de inquirepy 'default'.
• Ga je weer vooruit naar een volgende vraag, en je hebt eerder al een antwoord voor deze vraag gekozen, dan is dat de 'default' voor de inquirepy vraag.
• Om er voor te zorgen dat je wel weer door alle vragen gaat, opslaan bij welke vraag de gebruiker is gebleven.
  Anders krijg je dat wanneer de gebruiker de applicatie opstart hij weer aan het einde start terwijl hij misschien ook de eerder vragen opnieuw wil of moet invullen. De state zal ze namelijk overslaan omdat ze al ingevuld zijn.
• Opslaan gelopen pad van vragen? Bij elk antwoord opslaan wat de vorige vraag was? Dan kun je ze herleiden of printen als overzicht.