Samenvatting
Advanced Software Development 1 (ASD1) Samenvatting
- Instelling
- Hogeschool Gent (HoGent)
Samenvatting van het vak Advanced Software Development 1 (ASD1), in het 2de bachelor van het traject Toegepaste Informatica (TI)
[Meer zien]Voorbeeld 10 van de 42 pagina's
Voorbeeld 10 van de 42 pagina's
In winkelwagen
Voorbeeld van de inhoud
Advanced Software Development 1Tom De Bakker
23/12/2023
1
,Inhoudstafel
1 Advanced Software Development 1 4
1.1 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Test Driven Development 5
2.1 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Werken met Visual Paradigm en IntelliJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Belangrijkste relaties in Visual Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Een Hello World project om te leren werken met JUnit . . . . . . . . . . . . . . . . . . . . 6
2.2 Mocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Dependencies: wat? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Dependencies: probleem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Oplossing: Mock object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.4 Dependency injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Mockito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Code voorbereiden voor Mockito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Testklasse met Mockito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Oefening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Design Patterns 13
3.1 Inleiding design patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Ontwerprincipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Strategy pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Waarom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Stappen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3 Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Simple factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 Waarom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 Stappen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3 Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Observer pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.1 Waarom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2 Stappen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.4 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Decorator pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1 Waarom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.2 Stappen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.3 Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.4 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6 State pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6.1 Waarom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6.2 Stappen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6.3 Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6.4 UML & Toestandsdiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6.5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Facade pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7.1 Waarom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7.2 Stappen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7.3 Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7.4 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7.5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.8 Design patterns door elkaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8.1 Oefening 3: Rol verkeerd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2
, 3.8.2 Oefening 4: Printer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8.3 Oefening 5: Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.9 Oefening 1: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.10 Oefening 2: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.11 Oefening 7: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Java 32
4.1 Collections & Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1 Overzicht collection framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2 Map interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.3 Synchronized wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.4 Checked wrappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.5 Oefeningen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1 List<T> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.1 Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5.2 Java type erasure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Networking 38
5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Socket-programmeren met TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.1 Een eenvoudige Server met Stream Sockets opzetten in 5 stappen . . . . . . . . . . . . . . 38
5.2.2 Een eenvoudige Client met Stream Sockets opzetten in 4 stappen . . . . . . . . . . . . . . 40
5.2.3 De klasse InetAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3
, 1 ADVANCED SOFTWARE DEVELOPMENT 1
1 Advanced Software Development 1
1.1 Evaluatie
• 2 uur op papier: gesloten boek
∘ Java
■ Mappen
□ Heel de inhoud van de Map zien als een string
□ Zet een lijst van gegevens om in een map
■ Netwerken
■ Generics
∘ JUnit & Mockito
∘ Design patterns
■ Open vragen:
□ Weten welk DP je dient te gebruiken + toepassen (klassendiagram en implementatie)
■ Deze code deugt niet, schrijf enkele regels erbij/pas aan
■ Ze geven een klassendiagram, en je moet dan de code geven die daarachter zit
• De syntax is niet het belangrijkste (exacte naam van methoden, puntkommas, …), het idee is belangrijk
• Het bijlagen ASD1 wordt gegeven tijdens het examen en bevat de delen van de API die we gebruiken
4
, 2 TEST DRIVEN DEVELOPMENT
2 Test Driven Development
2.1 JUnit
2.1.1 Werken met Visual Paradigm en IntelliJ
1. Maak een nieuw Java project in IntelliJ
2. Rechtsklik op de naam van het project in het Project venster > Visual Paradigm Standard > Open
Visual Paradigm Standard
3. Klik op Create or select existing project at external location
VP zal opstarten en de licentie key controleren. Links komen er ook 2 nieuwe icoontjes/tabjes: Project
Explorer en Properties Pane
4. Klik op Project explorer > Diagram Navigator > UML Diagrams > Class Diagram, rechter
muisknop > New Class Diagram
5. Kies links voor Package , geef het de naam “Domein”
6. Kies links voor Class , geef het de naam “Weegschaal”
7. Rechtermuisknop op de aangemaakte klasse Add > Attribute
• Syntax:
∘ +attribute (public)
∘ -attribute (private)
∘ #attribute (protected)
∘ <<Property>> -attribute (attribute die automatisch een getter en setter heeft van de vorm:
getAttribute en setAttribute )
8. Rechtermuisknop op de aangemaakte klasse Add > Operation
1. Syntax:
• public/private/protected is hetzelfde zoals bij de attributen
Bij het definieren van functies in dit UML diagram, altijd alles erin opnemen. Public/private
of protected, types van de argumenten, return type etc.
9. Om ons gecreëerde UML diagram om te zetten naar Java code; rechtermuisklikken op de klasse en
Update to Code selecteren
1. Of we kunnen het volledige ULM diagram omzetten naar Java code door: Diagram Navigator >
Update Code
Meestal zullen we enkel hetgeen dat we hebben aangepast, een specifieke klasse, willen omzetten
naar Java code; niet het volledige UML diagram. Dit om te voorkomen dat we reeds geimple-
menteerde Java code vervangen door UML placeholder code.
10. Wanneer we aanpassingen hebben gemaakt in de code, kunnen we ook het UML diagram updaten op
basis van de geschreven code.
Rechtsklik ergens in de code van de klasse: Visual Paradigm Standard > Update to Visual
Paradigm Standard
2.1.2 Belangrijkste relaties in Visual Paradigm
Gegeven het volgende voorbeeld:
Mens definieert wat je met een mens kan doen
Ik ben een mens
Ik heb een laptop
Als je mij iets vraagt dan gebruik ik een boek
5
,2.1 JUnit 2 TEST DRIVEN DEVELOPMENT
Jan kan mij altijd vervangen ( dubbelganger ) maar als je iets vraagt is het
antwoord nogal kinderlijk
Dan kunnen we het volgende model schetsen:
Figure 1: Voorbeeld met de belangrijkste relaties in Visual Paradigm
De gebruikte relaties zijn:
1. Heeft (has a)
2. Is een (extend)
3. Is een (implements)
4. Is afhankelijk (dependency)
vraag() wordt bijvoorbeeld opnieuw geimplementeerd in Jan , omdat Jan niet antwoord op dezelfde
manier, maar op een kinderlijke.
2.1.3 Een Hello World project om te leren werken met JUnit
Alles dat hier wordt uigelegd staat vermeld in het project:
Advanced Software Development 1\ Practica \ ASD1_JUnit_Weegschaal
• Eerst en vooral hebben we natuurlijk JUnit nodig
∘ Open de pom.xml
∘ Alt + Insert en selecteer Add dependency…
∘ In de zoekbalk van het venster dat wordt geopend, zoek naar org.junit.jupiter:junit-jupiter
∘
Klik op Add
∘
Synchroniseer Maven zodat de dependency wordt gedownload
• We maken een test klasse met dezelfde naam als de klasse die we willen testen, maar met “Test” op het
einde van de naam in de folder src/test/java
∘ In deze test klasse doen we een static import van
import static org. junit . jupiter .api. Assertions .*;
Een static import staat ons toe om direct functies zoals assertEquals() te gebruiken in onze
code, inplaats er steeds Assertions.assertEquals() te moeten voorschrijven
• JUnit aanziet iedere methode van een Test Case die voorzien is van @Test als een methode die iets test.
∘
@Test
public void test ()
{
fail("Not yet implemented ");
}
6
,2.1 JUnit 2 TEST DRIVEN DEVELOPMENT
• De @BeforeEach annotation zorgt ervoor dat de methode eronder zal aangeroepen worden voor elke
test
∘
@BeforeEach // De methode hieronder zal elke keer opgeroepen worden
voor elke test.
public void before ()
{
weegschaal = new Weegschaal ();
}
• Een statisch method met @BeforeAll wordt eenmaal uitgevoerd, voor alle @Test methoden
• Een static method met @AfterAll wordt eenmaal uitgevoerd, nadat alle @Test methoden werden
uitgevoerd
Er zijn verschillende soorten testen:
• assertEquals(expected, actual, ?String message, ?delta)
∘ ? ervoor wil zeggen dat het optioneel is.
∘ Message als het niet gelijk is
∘ Delta = maximaal verschil
• assertTrue(boolean conditie, ?String message)
• assertFalse(boolean conditie, ?String message)
• assertNull(Object object, ?String message)
• assertNotNull(Object object, ?String message)
• Test niet te veel in één test
• Een @Test mag de werking van een andere @Test niet beinvloeden
• Alle @Test moeten in een willekeurige volgorde kunnen uitgevoerd worden
• Assertions.assertThrows(IllegalArgumentException.class, () -> ...)
∘ Indien de methode geen exceptie van het type IllegalArgumentException.class opwerpt, geeft
JUnit een error
@ParameterizedTest
@CsvSource ({"2.0 , 1.0 , 1.0", "3.5 , 2.5 , 1.0", "4.2 , 3.1 , 1.1"})
public void add( double expected , double valueOne , double valueTwo )
{
Assertions . assertEquals (expected , calculator .add(valueOne , valueTwo ),
0);
}
• ∘ Geparametiseerde testen roepen te methode meerdere malen op met verschillende parameters
•
@ParameterizedTest
@NullAndEmptySource // Dit geeft eens `null ` en "" mee als argument aan de
functie
@ValueSource ( strings = { " ", "a", "A" })
public void ongeldigTitel ( String titel )
{
Assertions . assertThrows ( IllegalArgumentException .class , () ->
hoofdstuk . setTitel ( titel ));
}
private static Stream <Arguments > addFixture ()
{
return Stream .of(
Arguments .of(new int []{5} , 5) ,
Arguments .of(new int []{2 , 3}, 5) ,
Arguments .of(new int []{5 , 6, 9}, 5)
);
7
,2.2 Mocking 2 TEST DRIVEN DEVELOPMENT
}
@ParameterizedTest
@MethodSource (" addFixture ")
public void voorbeeldTest (int [] getallen , int resultaat )
{
Assertions . assertEquals (resultaat , eenKlasse . verwerking ( getallen ));
}
• ∘ Opsomming hergebruiken voor meerdere parameterized testmethoden.
∘ Kan één of meerdere waarden bevatten. Kan objecten bevatten.
2.2 Mocking
In Test-Driven Development (TDD), mocking is a technique used to isolate the code being tested by replacing
certain components or dependencies with simulated objects or functions, often referred to as “mock objects”
or “mocks.” The primary purpose of mocking is to create controlled and predictable environments for testing,
allowing you to focus on testing a specific piece of code in isolation. Mocking is commonly used when testing
code that interacts with external systems, databases, or services, as well as when testing code that uses complex
or time-consuming operations.
2.2.1 Dependencies: wat?
Als klasse A in een methode een methode oproept van klasse B, heeft klasse A een dependency op klasse B
Figure 2: UML diagram van klasse A met dependency op klasse B
public class A {
public void methodA () {
B b = new B();
int i = b. methodB ();
}
}
public class B {
public int methodB () {
return 123;
}
}
2.2.2 Dependencies: probleem
In business applicaties hebben veel klassen dependencies, dit leidt tot problemen bij het unit testen.
• Als je een unit test doet van klasse A, voer je ook code van de klasse B uit. Je test dus niet één klasse,
maar meerdere klassen.
• Als de code van klasse B traag is, is het unit testen van klasse A traag
• Als klasse B nog niet geschreven is kan je klasse A niet unit testen
• Als klasse B een user interface is, kan je klasse A niet unit testen zonder interactie met de gebruiker
• Het is soms moeilijk het gedrag van klasse A te unit testen in het geval dat klasse B exceptions werpt
• Testen met databases zijn vaak te traag
8
,2.2 Mocking 2 TEST DRIVEN DEVELOPMENT
2.2.3 Oplossing: Mock object
Mock objecten in de context van unit tests zijn “nep”-objecten die het gedrag van echte objecten simuleren
wanneer een echt object (of diens gewenst gedrag) niet makkelijk beschikbaar is.
De gemockte objecten worden gebruikt door echte code die getest wordt. Het mock object wordt door
“Dependency Injection” in de echte code geplaatst.
Tijdens de echte uitvoering gebruikt klasse A de echte klasse B.
Figure 3: UML van de echte uitvoering
Tijdens het uitvoeren van unit tests maakt klasse A echter gebruik van de Mock-klasse. Deze Mock-klasse heeft
dezelfde methoden als de echte klasse B, maar in deze methoden wordt minimale functionaliteit geïmplementeerd.
Het belangrijkste doel is om de verwachte output te produceren die klasse A nodig heeft.
Figure 4: UML tijdens een test
2.2.4 Dependency injection
Dependency injection (DI) is a software design pattern used in object-oriented programming to achieve Inversion
of Control (IoC) and manage the dependencies between different components of an application. In a nutshell,
it is a technique for providing the required dependencies (e.g., objects, services, or configurations) to a class
or component from external sources rather than having the class create or manage them itself. Dependency
injection can be achieved using a constructor which takes the dependency or by creating a setter which sets the
dependency on the object.
Concreet kunnen we dit doen door klassen BImpl en BDummy allebei dezelfde interface B te laten
implementeren. In de klasse A , druk je de dependency dan uit adhv een private variable die als type de
B interface heeft.
Vervolgens maken we in de klasse A ofwel een constructor die als één van de parameters een object van het
type B neemt. Of een set methode die kan gebruikt worden om een object van het type B te setten in
de klasse A . Wanneer er wordt getest, wordt aan de klasse A een object van de klasse BDummy gegeven.
Tijdens de echte uitvoering wordt er dan een object van de klasse BImpl meegegeven.
9
, 2.3 Mockito 2 TEST DRIVEN DEVELOPMENT
Figure 5: UML diagram van dependency injection
2.3 Mockito
Wanneer we het framework Mockito gebruiken, kunnen we zeggen maak van deze klassen een Mock object. Dan
laten we aan Mockito weten voor welke methode oproep, welke output we verwachten. Mockito creert dan een
Mock object met de gewenste functionaliteit. We moeten die functionaliteit dus zelf niet expliciet implementeren
voor het Mock object.
2.3.1 Code voorbereiden voor Mockito
Indien we een bepaalde klasse willen testen adhv Mockito, moeten we ervoor zorgen dat Mockito aan dependency
injection kan doen. Mockito probeert in eerste instantie de constructor te gebruiken voor het meegeven van de
dependency/Mock-object. Als dat niet mogelijk is, maakt Mockito gebruik van de settermethode.
De te testen klasse moet aan de volgende drie criteria voldoen:
1. Ze moet een private attribuut bevatten met hetzelfde type als de betreffende dependency.
2. Er moet een constructor of setter beschikbaar zijn voor dependency injection.
Indien er gebruik gemaakt wordt van een constructor voor dependency injection, dient er ook een
default constructor aanwezig te zijn voor wanneer de “echte” code wordt uitgevoerd die geen gebruik
maakt van dependency injection.
3. Alle code die dependencies zelf aanmaakt, zonder het object te gebruiken dat is ingesteld door de depen-
dency injection (indien aanwezig) moet worden verwijderd.
2.3.2 Testklasse met Mockito
Mockito allows you to create mock objects that simulate the behavior of real objects and helps you isolate the
code you want to test by replacing its dependencies with these mock objects. Here’s how Mockito works in
JUnit/Java:
0. Setup Mockito Test Class: Ensure that your test class is marked with the @Extend
With(MockitoExtension.class) annotation to set up the Mockito extension. This ensures proper
initialization of your mocks and their injection into the test class.
•
@ExtendWith ( MockitoExtension . class )
public class MyServiceTest { ... }
1. Declare The Class Under Test: Declare the class you want to test and annotate it with @InjectMocks
.
•
@InjectMocks
private MyService myService ;
• Dependency Injection: Mockito helps with dependency injection in unit tests. In a typical Java
application, classes often depend on other classes. In unit tests, it’s a good practice to isolate the
class you want to test and replace its dependencies with mock objects.
2. Mock Creation: You can create a mock object using the Mockito.mock() method, passing in the
class or interface you want to mock. Or alternatively using the @Mock annotation. For example:
10
Voordelen van het kopen van samenvattingen bij Stuvia op een rij:
√ Verzekerd van kwaliteit door reviews
Stuvia-klanten hebben meer dan 700.000 samenvattingen beoordeeld. Zo weet je zeker dat je de beste documenten koopt!
Snel en makkelijk kopen
Je betaalt supersnel en eenmalig met iDeal, Bancontact of creditcard voor de samenvatting. Zonder lidmaatschap.
Focus op de essentie
Samenvattingen worden geschreven voor en door anderen. Daarom zijn de samenvattingen altijd betrouwbaar en actueel. Zo kom je snel tot de kern!
Veelgestelde vragen
Wat krijg ik als ik dit document koop?
Je krijgt een PDF, die direct beschikbaar is na je aankoop. Het gekochte document is altijd, overal en oneindig toegankelijk via je profiel.
Tevredenheidsgarantie: hoe werkt dat?
Onze tevredenheidsgarantie zorgt ervoor dat je altijd een studiedocument vindt dat goed bij je past. Je vult een formulier in en onze klantenservice regelt de rest.
Van wie koop ik deze samenvatting?
Stuvia is een marktplaats, je koop dit document dus niet van ons, maar van verkoper TomDeBakker. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor €5,49. Je zit daarna nergens aan vast.
Is Stuvia te vertrouwen?
4,6 sterren op Google & Trustpilot (+1000 reviews)
Afgelopen 30 dagen zijn er 81849 samenvattingen verkocht
Opgericht in 2010, al 14 jaar dé plek om samenvattingen te kopen