C++ och dess framtid att programmera minnessäkert - Hur går utvecklingen?

Ja, certifieringen kräver ett omfattande testarbete. Om du nu skall styra rymdraketer, flygplan eller kärnkraftverk har beställaren ställt upp kriterier som måste uppfyllas för att programvaran skall godkännas. Certifieringen görs typiskt av tredje part som skall sätta sin stämpel på att alla krav har uppfyllts. Då krävs det att det finns tester enligt den specifikation som skall följas.

När jag läser ditt inlägg får jag intrycket att du lägger skulden på programmerarna. Inte att beställaren har lagt en testbörda på dem. Utan programmerarna är klåpare som behöver skriva tester och för att de skriver tester kommer inte projektet bli klart i tid, segt att jobba i. Det kommer att misslyckas.

Slutligen kommer kronan på verket: "Det är därför enhetstester är totalt värdelöst". Än en gång har du tappat bort mig i resonemanget. Enhetstester suger för att ...? Och hur relaterar det till kod-certifiering?

Fast vad har du "förklarat"?

Att det är dyrt att utveckla kod där testningen är på en nivå som krävs för certifiering är ju ingen nyhet, det finns redan massor med konkreta exempel på det vilket är också är huvudorsaken till att man inte testar på den nivån om det inte är ett hårt krav. Det trots att det är uppenbart vilken hög kvalité kod som är certifierad mot krav likt DO-178C är i praktiken.

Vad du överhuvudtaget inte lyckats förklara är hur "normal" användning av unit-testing skulle bli dyrare än att säga "skriv rätt från början!!!", sedan hoppas att det blir så och hantera problemen när de kommer in från fältet.

Att skriva bra tester är något man måste lära sig. Överlägset vanligaste misstaget är att man försöker testa den valda implementationen, det gör det väldigt tungrott om/när man sedan försöker ändra något.

Det man ska testa är förväntat externt observerbart beteende av sitt API, så länge inte APIet ändrar vad det utför och hur dess signatur ser ut krävs inga ändringar alls i testerna (tvärtom blir då testerna ett snabbt/effektivt test på att man inte pajat något som tidigare fungerade när koden ändras).

Om man vänder på frågan: på något sätt måste man ju ändå förvisa sig om att koden fungerar som tänkt. Hur anser du att det görs i det ideala fallet (och hur är det snabbare/effektivare än TDD)?

Fast nu känns det som du rör ihop saker igen. Coupling har ju med arkitekturen i övrigt att göra och inget med unit tester.

Om du nu tvunget vill applicera coupling-perspektivet på unit tester så kommer ju unit testerna vara start kopplade mot koden som du testar men det är ju helt naturligt och inte unikt för unit tester, all typ av testning kommer vara starkt kopplad till koden som dom testar. Sedan koden som testas har ju ingen koppling till testet så ur det perspektivet så borde det ju vara skitbra i dina ögon.

Coupling handlar ju framförallt om väldefinierade interface i din kod så att det inte sker anrop kors och tvärs utan eftertanke och som tidigare sagt man brukar aldrig inkludera tester i det perspektivet för då har man missförstått något. Jag har t o m för mig att unit tester kan fungera som en indikator för att din kod är för hård kopplad om du upplever det svårt att skriva unit testerna.

Det känns som du hört "coupling är dåligt" utan att förstå konceptet.

Det är en skill-issue! TDD m.h.a. unit-tester är programutveckling precis som all kod.

De som får problem med unit-tester ihop med TDD skriver sina tester med 1-till-1 mappning mot koden de tester, d.v.s. fallet till vänster. Det kan vara OK för enklare fall, men det kommer antagligen bli ett problem i mer komplexa fall.

Lösningen?

Exakt samma som vilken kod som helst där man kan ana att saker lär ändras framöver: man skapar en lokal abstraktion som man primärt skriver sina tester mot, inuti denna anropas produktionskoden som testas. D.v.s. fallet till höger.

Om/när något förändras i produktionskoden och man inte totalt ändrat vad den faktiskt gör kommer nu testerna initial gå sönder men kommer krävas en relativt modest förändring i den abstraktion man gjort. Själva testerna kommer i nära nog 100 % av fallen fortfarande vara helt orörda.

Så ja, man kan absolut köra i diket med TDD/unit-tester. Men det beror på bristande kunskap, inte att TDD/unit-tester är fundamentalt trasigt.

Tvärtom ser vi att "alla" insett deras värde till sådan grad att i praktiken alla relevanta programspråk har en eller flera de-facto standard ramverk för att göra detta och blir allt vanligare med en "riktig" standard i form av standard-tool-chain har stödet integrerat på samma sätt som ett standardbibliotek är integrerat.

Om du plockar bort en metod då kan du plocka bort testet/testerna relaterade till metoden dvs minimalt med arbete.

Jag sa ju att om du tvunget vill adressera coupling och cohesion när det kommer till unit tester så kommer testerna vara kopplade med koden. Du kan ju exempelvis plocka bort testerna utan att koden slutar fungera så åt det hållet har du ju inga kopplingar. Sedan har du ju sagt att du testar på andra sätt, du har nämnt regressionstester, behöver inte dessa tester uppdateras om du ändra interface? Isf har du ju coupling fast på en annan nivå bara.

Om du ändra en metods parametrar så visst du kommer behöva göra en minimal ändring i ditt unit test men du måste ju även uppdatera dina asserts så mängden arbete lär var likvärdigt.

Att lägga till funktionalitet är det triviala fallet, behövs lite nya tester för de nya funktionerna.

Om saker ändras, finns i huvudsak två fall.

1. APIet förändras i specifika detaljer, då ändras abstraktionen men i de flesta fall påverkas inte testerna alls då man fortfarande testar samma sak.

2. Funktion tas bort (i praktiken väldigt ovanligt, men händer). Då lär också vissa tester tas bort.

Inte mer "om" än vilken kod som helst. Det är faktiskt normalfallet idag att ha den här typen av tester, så svårt kan det inte vara.

Har själv jobbat med det i allt från kod som är några tusen rader till kodbaser med årtionden med "legacy" som totalt är många miljoner rader kod.

Nu har jag en stor del av mitt arbetsliv jobbat med OS-kärnor och kringliggande systemtjänster, där ändrar man inte ett publicerat API och man vill ha kvar några kunder. Så att testa "customer-facing" delarna är rätt mycket ett icke-problem ur den aspekten.

Krävs lite mer när man tester interna APIer som man vill kunna ändra, men har man en någorlunda populär produkt lär man sig rätt snabbt att Hyrums lag tyvärr stämmer. Så i praktiken måste man alltid tänka till när man ändra sakers. Men går absolut att använda TDD i produkter där i stort sett hela koden är "intern" (man gör ett program folk använder via UI), jobbar specifikt med ett sådan fall just nu där TDD appliceras.

Så självklart finns utmaningar med TDD/unit-tester. Men tror den delen jag överhuvudtaget inte begriper är vad du anser är den bättre lösningen. För mig låter det verkligen som du anser "gör rätt från början, då behövs inga tester, ett gäng asserts fixar biffen!". Hel-coolt om det fungerar för dig, det är ett säkert recept för katastrof för de flesta.

Är det inte lite lustigt att han som inte tycker tester behövs

talar om för oss, som vanemässigt skriver enhetstester och tycker att de hjälper oss i utvecklingen,

att vi inte vet vad vi håller på med?

Nu hoppade du över frågan som handlade om hur certifiering leder till att enhetstester är värdelösa. @Yoshman skrev att certifiering var dyrt och du avslutade ditt svar på det inlägget med "Det är därför enhetstester är totalt värdelöst". Jag skulle väldigt gärna vilja veta hur du resonerade när du kom till den slutsatsen.

Du erkänner att du inte skriver unit test medans vi andra skriver unit test. Jag tror därför att du har minst erfarenhet av att skriva test.

Jag tror att du är kass på att skriva unit test och därför vill du inte skriva unit test och därför predikar du om att unit test är värdelöst. Du kan helt enkelt inte arbeta med att koda inom safety(militär, fordon och med-tech) om du inte skriver unit test, kan du lista ut varför?

Eller för att man måste bevisa att ens kod fungerar och det räcker inte med "Trust me, bro".

Bland annat

Hur uppnår du motsvarande granularitet som ett unit test i ett automatiserat test utan att det klassas som ett unit test?

Där har du ju inte bevisat något mer än vad en bilförsäljare har, "Kolla bilen startar, där är inga fel på den".

I allt det du listade där så är jag övertygad om att bolaget använder unit tester. Iaf i TV, mobiler, övervakningskameror, möbelföretag, låstillverkare ...

Du är nog den första utöver juniora utvecklare som kommer färska från skolan som jag stött på som tycker att det är värdelöst. Juniora utvecklare erkänner iaf att dom inte gillar unit tester jobbigt för dom att skriva testerna(dina lata briljanta utvecklare ).

Det är ju fortfarande inte ett bevis för att mjukvaran fungerar så du hade fortfarande inte fått lansera en safety-reglerad produkt på marknaden.

Jag tror att din arbetsgivare hade varit jätteglad av att höra dig säga: "jag pallar inte skriva test men jag har testkört det på min dator utan några problem så vi borde release:a..."

Du får göra som du vill men jag hade varit nyfiken på vilket bolag du jobbar åt så jag kan undvika era produkter/tjänster?

Enhetstesterna är vad du gör dem till.

De låter dig på ett enkelt sätt verifiera att det externt observerbara i ett API beter sig som förväntat.

Täckningsgraden beror, precis som i all annan form av testning, på antalet tester du skriver. Om du tycker att de fångar för lite skriver du inte tillräckligt bra tester. Jag tycker det är mycket lättare att få hög coverage med enhetstester där jag kan skicka in de "intressanta" värdena direkt i ett funktionsanrop och verifiera att rätt värde returneras. Att få samma täckningsgrad med det du refererat till som regressionstester, där man startar hela applikationen, kör på viss input och verifierar mot förväntad output är mycket krångligare och dessa tester tar mycket längre tid att köra. Hela testprocessen blir mer tung och trögjobbad.

Vad menar du med att man snärjer in sig? Du har nämnt coupling. Jo, det stämmer att testkoden kommer anropa funktioner i ditt API. Det måste den rimligen göra om man skall anropa funktionen, men den anropade koden har ingen koppling till testerna. Så länge du håller dig till att testa det externt observerbara finns det inget som hindrar att refactoring eller utökningar av produktionskoden.

Räcker det med enhetstester? Nej, de garanterar inte på något sätt att enheterna kommer fungera ihop. Men om du på ett enkelt sätt kan verifiera att de olika enheterna var för sig beter sig som du förväntar dig så är det en bra start. Under resten av utvecklingen ger de en snabb återkoppling med små testfall där det är lätt att identifiera vad som ger fel svar och sannolikt lättare att hitta problemet än om du måste köra hela applikationen. En annan fördel är att de går att köra långt innan man har en färdig applikation.

Jag har ju frågat igen och igen hur du hanterar din testning. Som svar har jag fått asserts och regressionstester, men det ser jag inte som något som skulle revolutionera min testning. Upplys oss, utbilda oss i "annan teknik". Fräls oss!

Inte ett ord som har med testning att göra... Imponerande.