Regressionstester är till för att fånga buggar och fel som uppstått i system efter förändringar. Det är inte helt ovanligt att gamla buggar återuppstår (kanske i ny skepnad) i och med att nya vägar skapats genom programmet. Om man har 100 tester och skall göra en förändring i ett program, börjar vi med att skapa en baseline genom att köra de 100 testerna och ser hur många/vilka som passerar. Efter förändringen gör vi samma och jämför.
Ta fram en uppsättning regressionstester för en del av ett
program, motivera dem, och förklara vad testerna visar. (Ett test
är inte ett test om det inte är automatiserat, minst make test.)
En uppsättning regressionstester är ingenting man tar fram på en eftermiddag, utan de växer fram gradvis över tid. Vi kan t.ex. tänka oss att alla tester i den första sprinten under projektet är regressionstester. Att hantera och administrera regressionstester handlar inte bara om att ta fram nya tester vid behov (vilka?) utan också om ta bort tester (varför och när – kanske aldrig kommer upp under projektet).
Regressionstestning är viktigt för underhåll av kod eller vidareutveckling av en stor kodbas där effekterna av en förändring är svåra och kostsamma att spåra “manuellt”. Om man har en uppsättning regressionstester kan man köra dessa mellan förändringar för att se om förändringarna fått tester att misslyckas (alternativt börja fungera).
Regressionstester kan ha många olika format, bl.a. existerande enhetstest eller integrationstest, såväl som testfall skapade i samband med buggrapporter och buggfixar. I stora system kan regressionstesterna lätt bli svårhanterligt många.
Integrationstestning är konsten att ta olika moduler och visa att de fungerar tillsammans. Integrationstestning är separat från enhetstestning som försöker visa funktioner i enskilda moduler, och kan också vara betydligt mer komplicerat än enhetstestning eftersom det kan vara svårt att koppla samman moduler eller påvisa i vilken modul ett fel uppstår.
Report a bug on this achievement? Please place an issue on GitHub.