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

Har jag uppfattat det korrekt om jag drar slutsatsen att din bättre metod för att testa är att sprinkla koden med asserts? Hur kollar du då att den kan hantera alla fall korrekt? nullptr, randvärden, specialfall? asserts i koden kan ju bara reagera på det flöde som inkommande parametrar styr det till. Med unit-tester är det lätt att testa att de externt synliga funktionerna hanterar ett par typvärden och randvärden korrekt. Jag ser inte hur du får till det på ett enkelt sett med asserts.

Varför gör det koden trögjobbad? Om du upplever det tror jag att du försöker testa fel saker med dina unit-tester.

Min erfarenhet är att en uppsättning med vältäckande unit-tester är till stor hjälp. Jag gör inte färre fel, men oftast när jag gör fel får jag ofta veta det redan när jag försöker kompilera (och de automatiserade testerna körs). Felet har typiskt gjorts i det senaste jag ändrade och jag har testfall som påvisar exakt vad som går fel med den ändringen jag försökte göra. Utan dessa tester hade felet upptäckts i ett senare skede utan att jag har kvar kontexten i huvudet. I mitt fall sliter jag mycket mer med buggarna i legacy som saknar unit-tester.

Själv är jag av olika anledningar inte så förtjust i unit-tester, men en sak de är bra för är just regressionstestning.

Det är lätt att hävda att sin kod är felfri när den inte testas ordentligt. Jag har enbart observerat en person(djb) som har rätt till att skryta om detta och det är inte du.

Håller inte med dig. Lata programmerare skriver inte kod. Logiskt sett så skriver dom iaf mindre kod och om man skriver mindre kod så utvecklas man inte i samma takt som andra utvecklare och borde därför vara mindre produktiva och effektiva.

Nästintill aldrig. Jag använde det flitigt runt 2010 men sedan dess har jag inte jobbat för någon som tillåter det framförallt inte istället för testning. Jag använder asserts när programmet måste krascha och det är tillåtet att krascha programmet.

Personligen så gillar jag inte TDD och inte heller överdriven testning som att försöka uppnå 100% coverage. Jag tycker om att unit testa logik. Jag gillar det även för viss utveckling, t ex om jag ska utveckla en parser så är det ganska skönt att testa av allt eftersom man introducerar hantering av nya tokens, då är det lätt att kontrollera att tokeniseringen hanterar förväntade sekvenser.

Jag gillar även regressionstestning och som @Erik_T nämnde så är ju unit tester perfekta för detta.

Jo det vet jag därför det inte är svårare att reda ut än att mäta med och utan detta. För mig är det netto positivt.

Hmm... Du har uppenbarligen aldrig ens varit i närheten av säkerhetskritisk kod, t.ex. avionic system certifierade enligt DO-178C.

Där har du exempel på kod som efter den certifierats (är skitdyrt, kostar i storleksordningen 100 USD per rad kod) är helt fryst och kan ändå användas under årtionden.

Så finns definitivt fall där "kod aldrig ändrar sig" inom högst relevanta områden (finns något liknande för andra områden, men har själv bara jobbat med just DO-178C).

Hur är WPARAM/LPARAM på något sätt "ett naturligt sätt att tänka?". De är implementationsdetalj i Win32 APIet man behöver bry sig om på det lägsta nivån men som i en vettig design man lägger under en mer lämplig abstraktion där PostMessage/GetMessage i praktiken bara är en kommunikationsmekanisk för att schemalägga specifika kodsektioner+associerad data att köras på en specifik tråd (normalfallet är att man vill schemalägga något på GUI-tråden).

Det är dåligt om skill-level i att skriva bra unit-tester är så låg att det blir ett sänke. Finns absolut en lång rad sätt att skriva dåliga unit-tester som stjälper mer än hjälper. Men har man når "tillräckligt" hög skill-level i att skriva unit-tester har jag lite svårt att se exakt vad man kan ersätta det värde dess ger med något annat.

Använder också väldigt ofta assert. De har dock ett annat syfte jämfört med unit-tester och framförallt kan inte asserts testa saker som kräver ett större specifikt kontext för att trigga specifika fall.

Asserts huvudpoäng är dokumentation då de är ett bra sätt att uttrycka antaganden om t.ex. möjliga värden för argument, att man aldrig hamnar i ett icke-förväntat tillstånd under en beräkning etc.

Men normalfallet är väl ändå att asserts inte är med i release-byggen? Det tillåter att man ibland kan ha hyfsat komplicerade/dyra beräkningar för säkerställa att pre/post tillstånd är inom förväntade värden.

Fast här ser man också fördelen i att använda "memory safe languages", de har en lång rad implicita tester just kring att man inte hamnat i ett felaktigt tillstånd. I C och C++ behöver man lägga in allt det explicit i sin egen kod och i 3:e-parts kod har man kanske inte ens möjligheten om man saknar källkoden.

Nej för att asserter != test. assert är en typ av validering som terminerar programmet. Om du har ett program som hantera nätverkstrafik så är det ju vansinne att asserta på en trasig request.

Jag har varit med om fall där en oväntad ändring ledde till aktiverade asserts i release-kod. Jag även varit med om safety-kod där man använt assert som validering eftersom om valideringen misslyckades så kunde det leda till dödlig utgång och därför ville man att applikationen skulle krascha eftersom en krasch av applikationen innebar ett totalstopp av fordonet.

Jag använder debuggern för fullt men än en gång debugger(reflektera över namnet debugger) != test. Jag kör standalone gdb och DAP-integration för codelldb i neovim.

All kod bör vara säker. Vilket inte alls är samma sak som att all kod måste vara säker, och definitivt inte samma sak som att den faktiskt är säker.

Det är väldigt olika säkerhetskrav på kod som används i t.ex. ett spel eller ett ordbehandlingsprogram, och kod som används i styrsystemet för en jumbojet.
Om ett spel kraschar så är det trist. I värsta fall får man en massa skäll och måste betala tillbaka pengarna till missnöjda kunder.
Om en jumbojet kraschar så är det bokstavligen en katastrof, och sannolikt en massa dödsfall.

Det där du beskriver - kod som distribueras på fysiskt medium till kunder - det var ju det normala för kommersiella program förr i tiden, innan Internet blev vanligt. Det var rätt vanligt med fel av olika slag i programmen på den tiden också - enda skillnaden jämfört med idag var att företagen lade lite mer tid och resurser på att hitta och fixa problem innan man skeppade produkten. Oftast i alla fall.

Sorry, men jag förstår fortfarande inte. Hur gör du när du testar din kod? Du skriver att om du ändrar på koden måste du ändra på (unit-)testerna, men det är väl sant oavsett om du gör din testning i form av unit-tester eller regressionstester?

Och varför skulle koden bli långsam av att man testar en enhet i taget? Jag börjar tro att du har en egen betydelse för begreppet unit test. Kanske du kan beskriva vad du tycker att en unit test är, varför koden skulle bli långsammare och varför man efter en ändring i produktionskoden måste ändra på en unit-test men slipper ändra på tester i andra former av testning?

Mitt exempel hade inget med operativsystem att göra utan att du har programmerat något som ska vara exponerat för omvärlden.
Om du har skrivit en back-end med ett API som ska användas av folk då kan du ju inte krascha varje gång det kommer en trasig request i sådana fall har du ju skapat världen lättaste kod att DDosa och du kommer ha 0% uptime. I ett sådant scenario hade jag undvikit asserter för allt utom möjligen trasig konfiguration.

Fast man ser ju inte det omedelbart. Du måste ju fortfarande köra programmet och återskapa ett scenario som tar förväntad code path. Det fungerar ju fint i fall man har en lite applikation som arbetar ensam helt oberoende av miljön utan input. I mitt exempel med en back-end service så måste du ju säkerställa att alla konfigurerat nätverket på samma sätt och skrivit konfigurationsfilen på samma sätt och satt upp miljövariabler på samma sätt och slänga på en debugger för att se att det smäller på förväntat sätt. Det är många ställen det kan gå fel på i jämförelse med att skriva ett unit test där du skickar in förväntad och icke-förväntad input.

Vad gör du om du ska utveckla en produkt som har 20 systemtjänster som pratar kors och tvärs?

Här säger du först att kolla för programmeringsmissar och sedan pratar du om input-validering genom argument. Vad är det för fel på if (in == NULL) return -1;, istället för att krascha? Om du exempelvis tar emot en FILE* som argument så kommer ju den kunna vara NULL i produktion också där dina asserts var avslagna.

Denna delen är sann gällande asserts oavsett vad du kodar. Du ser asserten smälla omedelbart när applikationen är uppe och snurrar och du hamnar på en särskild code path. Om man har en komplex applikation så kanske det inte är det inte alltid så lätt att köra den.

Hur verifierar du din kod utöver att strössla den med asserts?

Windows kan så mycket att det enbart används på desktop.

Vad är fel med if (input == NULL) return -1; istället för en assert?

Det är fel fråga!

Rätt fråga är: finns det något som är mer effektivt än enhetstester för att göra X?

För egen del är svaret "nej" när TDD/enhetstester används på rätt sätt.

Det skrivet så är inte det den enda formen av testing som behövs!

Man kan använda allt på dåliga sätt. Men rätt använt har TDD, som primärt måste bygga på unit-tester, massor med fördelar som gör att utvecklingen går snabbare med ett bättre resultat.

1. Testerna blir den första användaren av det API man skapar. Är det svårt att skriva tester är det en stark indikation på att APIet är dåligt. Och med TDD är detta något man får väldigt tidigt, innan man ens börjat skriva koden som man testar -> ger snabbare iteration av en de viktigaste delarna (publika APIet).

2. Testerna blir det första lackmustestet av arkitekturen. En "code-smell" här är om mer än en handfull av testerna behöver saker som mock-up och/eller väldigt komplicerad setup/tear-down. En förkrossande majoritet av alla tester bör gå att köra utan mock-ups.

3. Andra former av tester kommer behövas. Rätt gjorda ska tiden det tar att köra alla unit-tester som mest handla om en handfull sekunder. Det gör möjligt att köra den typen av tester hela tiden och det är en enkelt sätt att sätta upp ett specifikt fall man kanske vill undersöka m.h.a. av debugger eller liknande. Finns tester som av nödvändighet kommer ta lite tid att köra, men de ska inte vara unit-tester!

package main

import "testing"

var input18 = []string{
	"2,2,2",
	"1,2,2",
	"3,2,2",
	"2,1,2",
	"2,3,2",
	"2,2,1",
	"2,2,3",
	"2,2,4",
	"2,2,6",
	"1,2,5",
	"3,2,5",
	"2,1,5",
	"2,3,5",
}

func TestDay18_1(t *testing.T) {
	world := parseCubeWorld([]string{"1,1,1", "2,1,1"})
	numFaces := CountFreeFaces(world.Droplets)
	if numFaces != 10 {
		t.Fatalf("Expected 10 free faces, got %d", numFaces)
	}
}

func TestDay18_2(t *testing.T) {
	world := parseCubeWorld(input18)
	numFaces := CountFreeFaces(world.Droplets)
	if numFaces != 64 {
		t.Fatalf("Expected 64 free faces, got %d", numFaces)
	}
}

func TestDay18_3(t *testing.T) {
	world := parseCubeWorld([]string{"0,0,0"})
	numFaces := world.CountExteriorFreeFaces(CountFreeFaces(world.Droplets))
	if numFaces != 6 {
		t.Fatalf("Expected 6 free exterior faces after filling with water, got %d", numFaces)
	}
}

func TestDay18_4(t *testing.T) {
	world := parseCubeWorld(input18)
	numFaces := world.CountExteriorFreeFaces(CountFreeFaces(world.Droplets))
	if numFaces != 58 {
		t.Fatalf("Expected 58 free exterior faces after filling with water, got %d", numFaces)
	}
}

Visa innehåll

Edit: Då debuggern är ett väldigt bra och kraftfullt verktyg är det rätt naturligt att utvecklingsmiljöer gör det trivialt att debug:a ett specifikt test eller benchmark (mikrobenchmarks är typiskt väldigt lika unit-tester). Unit-tester/benchmarks är del av standard tool-chain i Go, vilket gör det naturligt för VS Code och liknande att integrera detta

Finns två typer av säkerhet.

"Safety", skydda världen från programvaran/systemet. Är primärt detta man behöver garantera med de programvaror som kräver certifiering för att få användas.

"Security" är den andra formen där programvaran/systemet skyddas från världen. I de säkerhetskritiska fallen är nog detta rätt ofta löst genom att dessa system körs på isolerade system som är certifierade i sin helhet.

Vad dessa certifieringsmetoder visat är att men tillräckligt grundligg testing är det fullt möjligt att skriva nära nog perfekt programvara. I DO-178C är det inte ens C/C++ koden man certifierar, det är den assembler som faktiskt kör och kravet på de högsta nivåerna är 100 % line- (finns det instruktioner som inte körs ska de bort alt. så får man skriva en rapport på varför instruktionen finns när den inte körs) och state-coverage (d.v.s. varje villkorat hopp måste ha testfall för alla möjliga utfall).

Så det är i praktiken "perfekt" programvara, men enda sättet vi vet hur man kan skapa detta idag är så löjligt dyrt att det inte är användbart utanför de fall där den nivån är ett hårt krav.

Finns massor med anledningar varför det i praktiken inte alls är så enkelt och varför det kan vara fullt vettigt att även i release-läget ha kod som upptäcker fall som "inte borde hända".

För inte hävdar du att normalkodnivån är nära nog perfekt programvara???

I debug kan man då på en lite högre nivå just bara göra "assert(X)" för att få information om felet och försöka fixa det.

I release kan det vara så att man på en högre nivå har extra kontext. Man har nu konstaterat ett fel som t.ex. resulterat i att någon beräkning inte kan göras.

Om man måste ha resultatet finns inget annat att göra än att döda programmet och logga felet.

Men kan finnas andra fall där en sådant fel mest ger lite irritation, i det läget vill kan fortfarande avbryta i debug (för målet är att fixa felet) men i release kan man välja att köra vidare (vilket t.ex. leder till att inget händer när man trycker på en UI-knapp eller liknande) då det är mindre dåligt för upplevelsen än att döda hela programmet.

Då kan man inte använda asserts() för huvudsyftet med dessa är att testa saker som måste vara sanna, om de inte är det har programmet hamnat i ett tillstånd där det inte finns någon poäng att fortsätta -> enda vettiga är att logga felet och avsluta.

Va? Om det gör enhetstester värdelösa är i så fall även asserts helt värdelösa då de inte täcker 100 % av alla tänkbara fall!

Vad saker som Modified Condition/Decision Coverage visar är att det är möjligt att utföra testning på en sådan grundlig nivå att man kan bevisa att koder gör vad den är designat att göra. Men det är inte något man kan använda i det allmänna fallet då det är väldigt dyrt/arbetskrävande.

När unit-tester används för t.ex. TDD är man normalt sett inte i närheten någon perfekt "state-coverage". Det är inte heller målet, huvudmålet här är att på ett snabbt/effektivt sätt kunna testa APIet, verifiera att förändringar av koden inte ändrat externt observerat beteende, ge snabb access till fall där man vill undersöka koden m.h.a. debugger, etc.

Likt det mesta kräver lyckad användning av TDD att de inblandade har rätt kunskap. Precis som de iblandade behöver ha rätt kunskap om det/de programspråk och bibliotek som används för att det ska bli bra.

Ska inte tala allt för mycket för någon annan, men är 100 % säker att just det bara var ett exempel.

Ett mer "production ready" fall skulle kasta exception (om man gillar det, personligen anser jag att exception är goto-on-steriods och undviker det så långt som möjligt) eller ha en signatur där man returnerar ett värde när det går bra (Some(X) i Rust, icke-null nullable type i C#, std::optional<T> med ett värde i C++) och inget värde när det går dåligt. Sedan får högre nivå göra lämplig sak när det inte blev något värde.

Fast med din logik kring varför unit-tester är värdelös så blir även användning av assert helt meningslöst.

Unit-tester löser inte allt, men det finns saker de löser bättre än något annat och för det ska man använda dem.

WTF. @Yoshman skriver om att det är dyrt att certifiera programvara, på den nivån att den genererade koden granskas instruktion för instruktion. Då håller du med men lägger till att det beror på att programmerarna testar för mycket!?! Och att koden blir långsam för att de testar??? Hur tänkte du nu?