Bij het ontwerpen en beoordelen van testdata voor je functie `berekenSom(a, b)` is het belangrijk om verschillende soorten invoer te overwegen om de functionaliteit grondig te testen en mogelijke fouten te voorkomen. Hier zijn de belangrijkste categorieën en voorbeelden: 1. Normale gevallen (ideale invoer): - Doel: Controleren of de functie correct werkt onder standaardomstandigheden. - Voorbeelden: - `berekenSom(3, 5)` → verwachte output: 8 - `berekenSom(-2, 4)` → verwachte output: 2 - `berekenSom(0, 0)` → verwachte output: 0 2. Grenswaarden: - Doel: Testen bij de uiterste waarden die de invoer kan aannemen. - Voorbeelden: - Wanneer er geen maximale limiet is, kun je grote getallen testen: - `berekenSom(1e15, 1e15)` → verwachte output: 2e15 - Bij negatieve grenzen: - `berekenSom(-1e15, -1e15)` → verwachte output: -2e15 - Bij de limieten van JavaScript (bijvoorbeeld `Number.MAX_VALUE` en `Number.MIN_VALUE`): - `berekenSom(Number.MAX_VALUE, 1)` → mogelijk overflow of `Infinity` - `berekenSom(Number.MIN_VALUE, -1)` → controleer op onderloop 3. Ongeldige invoer: - Doel: Checken of de functie robuust is tegen ongeldige of onverwachte invoer. - Voorbeelden: - Niet-numerieke waarden: - `berekenSom('a', 5)` → verwachte gedrag: foutmelding of typecontrole - `berekenSom(null, 3)` - `berekenSom(undefined, 2)` - Arrays, objecten, functies als argumenten: - `berekenSom([1,2], 3)` - `berekenSom({a:1}, 2)` - Wanneer je functie strikt numerieke invoer verwacht, moet je testen of de functie hier correct op reageert (bijvoorbeeld door fouten te werpen). 4. Speciale waarden: - Doel: Controleren van randgevallen zoals `NaN` en `Infinity`. - Voorbeelden: - `berekenSom(NaN, 5)` → resultaat zou `NaN` moeten zijn - `berekenSom(Infinity, 1)` → `Infinity` - `berekenSom(-Infinity, -1)` → `-Infinity` Door deze verschillende testcategorieën te gebruiken, vergroot je de betrouwbaarheid en volledigheid van je tests. Het zorgt er ook voor dat je functie goed reageert op onverwachte invoer en dat je edge-cases afdekt. Kortom, je teststrategie zou er als volgt uit kunnen zien: - Test met normale, verwachte invoer - Test met grenswaarden en grote getallen - Test met ongeldige invoer en verkeerde types - Test met speciale waarden zoals `NaN` en `Infinity` Zo voorkom je bugs en zorg je voor robuuste code.

Absoluut! Laten we je functie `berekenSom(a, b)` grondig analyseren en effectieve testdata ontwerpen. ### Analyse van de Functie Je functie is eenvoudig: ze neemt twee parameters (`a` en `b`) en retourneert hun som. Hoewel de logica simpel lijkt, zijn er meerdere scenario's om te testen om robuuste en betrouwbare unit tests te garanderen. --- ### Soorten Testdata en Toepassing #### 1. Normale Gevallen (Happy Path) Dit zijn de typische, verwachte invoerwaarden waar de functie voor ontworpen is. * **Doel:** Verifiëren dat de kernfunctionaliteit correct werkt onder normale omstandigheden. * **Testdata Voorbeelden:** * `(2, 3)` -> Verwacht resultaat: `5` * `(-5, 10)` -> Verwacht resultaat: `5` * `(0, 42)` -> Verwacht resultaat: `42` * `(100, -100)` -> Verwacht resultaat: `0` #### 2. Grenswaarden (Boundary Values) Testen met waarden aan de uitersten of op de "rand" van wat relevant zou kunnen zijn. Voor een optelling zijn dit vaak de uiterste waarden die het systeem aankan (bijv. maximale/minimale getallen). * **Doel:** Fouten ontdekken die optreden bij uiterste invoerwaarden. * **Testdata Voorbeelden:** * **Grote getallen:** `(Number.MAX_SAFE_INTEGER, 1)` -> Verwacht: `9007199254740992` * **Kleine (negatieve) getallen:** `(Number.MIN_SAFE_INTEGER, -1)` -> Verwacht: `-9007199254740991` * **Nul:** `(0, 0)` -> Verwacht: `0` (ook een normale geval, maar een cruciale grenswaarde) #### 3. Ongeldige Invoer (Invalid Input) Dit zijn waarden die de functie *niet* zou moeten ontvangen, maar die in de praktijk door bugs elders in de code toch kunnen voorkomen. Het testen hiervan is cruciaal voor stabiliteit. * **Doel:** Controleren hoe de functie omgaat met foutieve invoer. Geeft het een voorspelbare fout? Crasht het de applicatie niet? * **Testdata Voorbeelden:** * `(null, 5)` * `(8, undefined)` * `("5", "10")` // Strings i.p.v. numbers * `(NaN, 7)` * `({}, [])` // Objecten en arrays **Belangrijke opmerking:** Je huidige functie heeft **geen foutafhandeling**. Deze tests zullen hoogstwaarschijnlijk falen of onverwachte resultaten opleveren (bijv. `"5" + "10" = "510"`). Deze tests zijn niet om de *huidige* functie te laten slagen, maar om de *vereisten* te definiëren. Moet je functie: 1. Deze invoer accepteren en proberen om te zetten? (Bijv. `parseInt(a) + parseInt(b)`) 2. Een duidelijke foutmelding throwen? (Bijv. `if(isNaN(a)) throw new Error("Parameter 'a' moet een getal zijn")`) Deze tests leggen de gewenste gedrag vast voordat je de functie aanpast. #### 4. Edge Cases met Drijvende Komma (Floating Point) JavaScript (en veel andere talen) heeft bekende precisieproblemen met drijvende-kommagetallen. Dit is een essentieel onderdeel van het testen van rekenfuncties. * **Doel:** Zorgen dat afrondingsfouten worden begrepen en correct afgehandeld. * **Testdata Voorbeelden:** * `(0.1, 0.2)` -> Verwacht resultaat: `0.3` ( maar het werkelijke resultaat is `0.30000000000000004`) * `(0.3, 0.6)` -> Verwacht: `0.9` **Hoe pas je dit toe?** Gebruik een assertie met een kleine tolerantie (delta) in plaats van strikte gelijkheid. ```javascript // Voorbeeld in Jest expect(berekenSom(0.1, 0.2)).toBeCloseTo(0.3); // Deze test slaagt // expect(berekenSom(0.1, 0.2)).toBe(0.3); // Deze test faalt ``` --- ### Concreet Testplan & Voorbeelden | Test Case Type | Input (a, b) | Verwacht Resultaat | Opmerking / Assertie Methode | | -------------------- | --------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | **Normaal** | (2, 3) | 5 | `expect(berekenSom(2, 3)).toBe(5);` | | **Normaal (negatief)** | (-5, 10) | 5 | `expect(berekenSom(-5, 10)).toBe(5);` | | **Grens (nul)** | (0, 0) | 0 | `expect(berekenSom(0, 0)).toBe(0);` | | **Grens (groot)** | (MAX_SAFE_INTEGER, 1) | 9007199254740992 | `expect(berekenSom(Number.MAX_SAFE_INTEGER, 1)).toBe(9007199254740992);` | | **Edge (float)** | (0.1, 0.2) | ~0.3 (afgerond) | `expect(berekenSom(0.1, 0.2)).toBeCloseTo(0.3);` | | **Ongeldig (string)** | ("5", "10") | **Fout** of **15**? | `expect(() => berekenSom("5", "10")).toThrow();` OF `expect(berekenSom(Number("5"), Number("10"))).toBe(15);` (na aanpassing) | | **Ongeldig (null)** | (null, 5) | **Fout** of **5**? (null wordt 0) | `expect(() => berekenSom(null, 5)).toThrow();` | --- ### Hoe dit de Betrouwbaarheid Verbetert 1. **Volledige Dekking (Coverage):** Je test niet alleen het voor de hand liggende pad, maar alle mogelijke paden en scenario's die zich kunnen voordoen. 2. **Vroegtijdige Foutdetectie:** Problemen met grote getallen, drijvende komma of ongeldige invoer worden vroeg in het ontwikkelproces ontdekt, niet pas wanneer een gebruiker ze tegenkomt. 3. **Gedocumenteerd Gedrag:** Je testsuite dient als levende documentatie van hoe de functie zich *moet* gedragen in verschillende situaties, inclusief foutscenario's. 4. **Toekomstbestendigheid:** Wanneer iemand later de code aanpast (bijv. voor optimalisatie), kunnen je tests direct waarschuwen als de wijziging onbedoeld gedrag in één van deze edge cases breekt. **Volgende Stap:** Bepaal hoe je functie *moet* omgaan met de ongeldige invoer. Implementeer die foutafhandeling en schrijf dan de bijbehorende tests. Dit maakt je code veel robuuster.