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

Om du ger en bra förklaring hur du kan testa den här koden utan att behöva skriva testkod i två veckor så skall jag berätta

#20955298

enhetstester har troligen blivit poppis för det är lätt att förstå för chefer som inte kan programmera

använder tester men inte för att testa kod, de är bra för annat. exempelvis att låsa kod

tack för hjälpen

 * This method processes a list of regex patterns and applies them to the files stored in the cache.
 * It generates a list of lines in each file where the patterns are found and stores the results
 * in the "file-linelist" cache table.

Om jag skall skriva test för det så är jag uppe i två veckor eller i alla fall väldigt mycket extra tid, metoden tog en kväll och skriva och testa i debug. Föredrar att bli klar någon gång

Min teknik för att testa domänkod är vanligen att skripta upp applikationen, kan lägga in LUA kod men i aktuell kod jag visade har jag funderingar på att använda python, mest för att lära och testa nu när python har möjlighet att köra utan GIL'en.

Skripta applikationen gör det enklare att skriva test, kan till och med vara helt andra eller om man vill introducera nya utvecklare i något så kan sådant passa bra.

För med enhetstest skapar du teknisk skuld och coupling, det låser kod.

Jag pratar inte om "hello world!"-applikationer eller enkelfunktionalitet. Det du beskriver måste vara mycket simpelt, annars är det inte möjligt att täcka 100%, och det vet du. Om en programmerare vore så skicklig (sådan existerar inte) att den klarar av att skriva tester som täcker allt, då skulle den programmeraren inte behöva skriva tester eftersom personen är så pass duktig att programmeraren skriver felfri kod direkt.

Enhetstester kommer i nära nog 100% av fallen kosta mycket mer än vad det ger.

Enhetstester har sin plats men då för andra orsaker (som jag nämnt, att låsa koden är ett exempel, man vill inte att den förstörs). Det kan vara att koden är så komplicerad att den inte går att förstå (kan vara trassel, domänen är är svår eller något annat). För att andra skall våga jobba med det kan de ha test så de får en säkerhet att det fortfarande fungerar som tänkt.

Såg du mitt exempel tidigare om en tabell som skrevs ut, det var ingen slump att jag la upp den koden men det verkar inte som någon nappar. Nu med LLMer är det himla smidigt och testa hur funktionalitet skrivs med andra språk, inte alls svårt.
Har inte sett att andra språk gör det enklare. Framförallt ser det "konstigt" ut. För något som C++ verkligen lyckats med är att det går att få ett mer naturligt utseende, det behövs inte lika mycket omskrivningar/anpassningar för att få till funktionaliteten. Och här sticker verkligen RUST ut, språkets tvingar utvecklaren skriva kod annorlunda.
OOP språk (C#, Java) lider också kraftigt av det problemet, att allt skall ligga i objekt är ett allvarligt designfel. Exempelvis svårt att avgöra vad som är bra skrivna objekt och vad som är hack eftersom allt MÅSTE ligga i objekt.

Det där är bara okunskap, och det är självklart eftersom den typen av kod är så ovanlig. De som lärt sig, där tror jag många likt mig undrar varför inte fler använder sig av tekniken med tanke på hur mycket det effektiviserar.
Tror det beror på att svårigheterna att diskutera teknik idag, går i princip inte om det blir svårare i allmänna/större grupper.

Två helt olika saker, statisk typning är att kompilatorn vet vad det är. Har inget med vad tagged unions försöker lösa. Templates som exempelvis kan upplevas som något som liknar, är bara att kompilatorn klarar generera kod. Är det fel på data i runtime har du inte en kompilator som kan kontrollera.
Tagged unions, då vet koden vad det är (maskinkoden)

Menar alltså inte att man inte skall ha något alls för att verifiera att allt fungerar som det skall.
Kod måste skrivas så den går att verifiera och då är det (alltid) data som verifieras, alltså resultat.

Med tagged unions det normalt enklare, går alltid och granska dataströmmar om man tänkt till och verifiera att de är ok.
Annars så hade nog jag försökt bygga några olika skriptlösningar som körde kod och matcha dem med tidigare resultat.

Repeterar igen:
Problemet med extra kod är att det låser koden. Du nämner själv att det: "behövde en par stycken småjusteringar p.g.a. förändring av API". Det låter på dig som att det där är ett någon enkelt, det är det inte när koden är svårare. Och ibland behövs större refaktoreringar, de kan bli en mardröm eftersom mycket mer kod behöver skrivas om.

Gissar att de flesta utvecklare låtit bli att skriva om kod just på grund av att tester gjort det mer eller mindre omöjligt.