OpenSUSE-KDE-Plasma Gambas 3.19.3 qt5

Een eigenaardig feonomeen: ik laat de gebruiker op de listbox klikken, waarop gevraagd wordt of hij de betreffende listbox lijn (aangeduid door Listbox.index) wil verwijderen. Zo ja, verwijder ik die met Listbox.Remove(Listbox.Index).

Mijn voorbeeld: de listbox (Mode: Single) bevat 1 lijn. Ik klik op knop 1.

Code:

Public Sub lsbxError_Click()
  Dim i As Integer
'  
  i = Message.Question(lsbxError.Index & ": " & lsbxError.Text, "Clear", "Clear All", "Cancel")
  Debug i
  Select i 
    Case 1
      lsbxError.Remove(lsbxError.Index)
    Case 2
      lsbxError.Clear
    Case 3
    ' else do nothing
  End Select
'
End

Na het verwijderen van de lijn krijg ik een nieuwe vraag met een lege tekst en als index -1. Als je nog eens op Clear klikt, krijg je een foutmelding Out of bounds
.. op de lijn van de Remove; het gaat blijkbaar over de index.

Ik merk op (bij meer elementen) dat de listbox na het verwijderen een ander item selecteert (zonder dat ik dat expliciet vraag), dat ik dan ook niet meer kan kiezen voor verwijderen.
Ik kan de fout blijkbaar vermijden door een “unselect” toe te voegen:

Public Sub lsbxError_Click()
  Dim i As Integer
  '
  i = Message.Question(lsbxError.Index & ": " & lsbxError.Text, "Clear", "Clear All", "Cancel")
  Debug i
  Select i 
    Case 1
      lsbxError.Remove(lsbxError.Index)
      lsbxError.UnselectAll()
    Case 2
      lsbxError.Clear
    Case 3
    ' else do nothing
  End Select
'
End

en de “index” fout kan ik vermijden door op voorhand een voorwaarde toe te voegen:

Public Sub lsbxLog_Click()
  Dim i As Integer
  
  Debug lsbxLog.Index
  If lsbxLog.Index >= 0 Then
    i = Message.Question(lsbxLog.Text, "Clear", "Clear All", "Cancel")
    Select i
      Case 1
        lsbxLog.Remove(lsbxLog.Index)
        lsbxLog.UnselectAll()
      Case 2
        lsbxLog.Clear
      Case Else
        ' else do nothing
    End Select
  Endif
  
End

Testen

Ik gebruikte al verschillende manieren om mijn programma’s te testen:
– ik dump allerlei waarden naar de output met print (die blijven ook werken in uitvoerbare programma’s)
– ik dump allerlei waarden naar de output met debug (die worden er uit gehaald bij compileren als je dat kiest)
– ik neem testcode op in mijn applicatie en stuur de uitvoer naar een optioneel zichtbaar te maken “log” (bestand of tekst op scherm).
– bij libraries schreef ik de testen in de main module, omdat die toch niet geëxporteerd wordt, dus niet zichtbaar wordt voor gebruikers. Wordt snel te veel.
– ik maak een aparte module “MTest” waar ik alle tests in steek. Ik moet die dan nog wel aanroepen uit bv de Main (library) of kan ze zelfs vanuit mijn draaiende applicatie aanroepen (bv via een testmenu in “hidden developer mode”).
– ik schreef een library MijnLib en maakte een testprogramma MijnLibTest en riep de testen aan vanuit Main, en zet ze aan of af door een commentaarteken voor de lijn te wissen/zetten. Wordt ook snel onoverzichtelijkt.
Maar dat is nog geen unittesten…

Formeel geÏntegreerd
Zoals altijd bij Gambas (althans mijn ervaring): als je iets nodig hebt, blijkt het ofwel al te bestaan, ofwel wordt het bijgemaakt, en kan je je eigen methodes vervangen door de geïntegreerde methodes in Gambas zelf.

Bij gebruik van de Gambas3 IDE viel me op dat er bij creatie van een nieuw bestand onder “bronnen”, behalve de opties “map”, “klasse”, en “module”, ook een optie “Test module” bestaat. Die maakt standaarde de testmodule “Test1” aan (die als bestandsnaam “Test1.test” heeft).
Waarschijnlijk is het overzichtelijker om een map te maken voor je tests (zoals ze in het voorbeeld doen); dus maak je eerst submap “Test”, en daarin de “Test1.test”. De testbestanden worden gebruikt in volgorde van hun bestandsnaam, en binnenin op volgorde van de methodenamen.
Een testmodule is in de linkse kolom herkenbaar aan een iets ander icoontje: een optionbox (aanvinkbaar hokje), en bij conventie laat je de naam voorafgaan door een T: TNaam (vgl module MNaam, form FNaam, class CNaam)

In de programmeeromgeving van Gambas3 druk je op F4 om de testen te starten.
Onderaan krijg je een vensterdeel met de resultaten van de tests. Bij het uitvoeren van de tests wordt een teller bijgehouden en onderaan krijg je een resultaat, bv als alles goed ging “PASSED”, anders “FAILED”.

Om de testen op te stellen heb je “Assert” te hulp:

Assert.Equals(uitdrukking1, uitdrukking2, commentaar)
Assert.Ok(uitdrukkingIsTrueOrNot, commentaar)
Assert.Error(commentaarBijErrorInTry_Something)
enz, Assert heeft een heleboel nuttige tests.

Gebruik
Als je helemaal nog geen code hebt, en gewooen een nieuwe test maakt “Test1”, en je probeert F4 krijg je:

1..0

# Ran ‘Test1’
#
# FAILED

En de voorbeeldcode (zie link onderaan) draait een succesvolle test en geeft:

1..5

Test THello.AHelloWorld
# I am the first test, because my name starts with A.
ok 1 – THello.AHelloWorld.7: HW strings should be equal
1..1
ok 1 – THello.AHelloWorld
(…enz 2, 3, 4 ..)
Test THello.Right
ok 1 – THello.Right.19: Hello.Right says Right
1..1
ok 5 – THello.Right

# Ran ‘Testsuite: A: Run all tests’
#
# PASSED

Verfijnen
Als je wil kunnen kiezen welke tests je wel of niet draait, kan je “test suites” maken. In het test scherm (F4) krijg je rechts onderaan de knop om “Test suites” te maken, -draaien, -beheren, enz.

Plannen
Het is lonend om bij het programmeren voor bepaalde methodes/procedures/functies eerst de test te programmeren, en dan pas de methode zelf: je kan dan tijdens het programmeren van de methode onmiddellijk testen met je test.
Als je later aanpassingen aan je programma maakt, bedenk je eerst of de test moet veranderen, en daarna kan je de wijzigingen dan ook testen met je oorspronkelijke of aangepaste test.
Vooral bij libraries zijn testmodules interressant, ook voor algemene code in modules in je project.

Links
https://gambaswiki.org/wiki/doc/unittesting
https://nl.wikipedia.org/wiki/Unittesten
https://gitlab.com/gambas/gambas/-/blob/master/main/lib/test/gb.test/unittesthelloworld-1.0.0.tar.gz