Daar gingen we dan. Maar liefst 14 collega’s van Craftsmen naar San Francisco om de grootste developer conferentie bij te wonen op het gebied van Java: Oracle Code One. The Conference Formerly Known As Java One.
Oracle Code One is een vierdaags event, van maandag tot en met donderdag. Doordat wij de zaterdag ervoor arriveerden en de vrijdag erna weer huiswaarts keerden, was er genoeg tijd voor sightseeing én om de jetlag te verwerken.
De dagen voor Oracle Code One
De eerste dag hebben we voornamelijk de omgeving verkend (lees: we zochten een bar op). Na het eten lagen we allemaal op tijd onder de wol, omdat we redelijk moe waren van de reis en omdat we de volgende dag in de vroege ochtend een fietstocht door San Francisco voor de boeg hadden.
Die zondag waanden we ons allemaal even Tom Dumoulin. Het was heuvelop en heuvelaf, staand op de pedalen, alsof er belangrijke punten voor de bolletjestrui te verdienen waren.
De Golden Gate brug was zo ongeveer het meest vlakke deel van de fietstocht.
Na deze Tour de California hebben we een welverdiend biertje gepakt en zijn we naar het Moscone Center gegaan om de toegangspassen voor Oracle Code One op te halen. Deze zou de volgende dag van start gaan!
Moscone Center dus. Met in 40 zalen, in 4 dagen, meer dan 600 sessies, verzorgd door mensen uit alle hoeken van de wereld. Over programmeertalen, technologieën en toepassingen hiervan.
Collega Michel Schudel mocht ook een sessie verzorgen, omdat hij genomineerd was als een van de beste nieuwkomers op jFall en daardoor een timeslot op Oracle Code One had gewonnen.
Highlights Oracle Code One
Er zijn van die momenten dat je als Software Engineer denkt: “Ik heb echt slimme code geschreven om het probleem op te lossen.” Van die momenten dat je trots bent op jezelf en dat je de code wilt uitprinten om boven je bed te hangen.
Moet je ook vooral doen natuurlijk. Maar vaak is de unit-test voor jouw slimme oplossing bijna net zo belangrijk en die krijgt niet in alle gevallen dezelfde aandacht. Daarom ligt de focus in deze blog op unit-testing.
Mockito 3
December dit jaar komt Mockito 3 uit. Een test-framework geschreven in Java waarmee, door het mocken van afhankelijkheden in de code, leesbare unit-testen te maken zijn.
Mockito 3 is in de basis Java 8 met standaard strict stubbing. Strict stubbing zorgt ervoor dat een unit-test faalt als er ongebruikte mocks in de test aanwezig zijn. Hierdoor krijg je geen onnodige mocks wat zorgt voor meer leesbare en duidelijke unit-tests.
Strict stubbing is overigens een optie die al in Mockito 2 zit, maar deze staat default uit. Zo zet je strict stubbing aan in Mockito 2:
@Rule public MockitoRule rule = MockitoJUnit.rule().strictness(Strictness.STRICT_STUBS);
Nog een verbetering in de nieuwe Mockito-versie is het debuggen bij een falende unit-test. Het komt weleens voor dat je een typo maakt bij het aanmaken van een mock. In Mockito 2 geeft een incorrecte mock een lege String terug, wat ervoor zorgt dat er uiteindelijk een assert fail optreedt.
Dan moet je als ontwikkelaar de hele unit-test door en elke mock nalopen om te kijken waar de fout kan zitten.
In Mockito 3 retourneert zo’n incorrecte mock geen lege String, maar een null waarde. Deze mock wordt vervolgens verderop in de code aangeroepen (als dit niet het geval was, had de test wel gefaald op de strict stubbing) en levert hij een NullPointerException op. Je ziet dan direct op welk punt in de code dit is, waardoor je sneller achterhaalt waarom die mock niet het gewenste resultaat geeft.
Unit-testen die uitgevoerd worden vanuit een IDE (bijv. IntelliJ) worden bovendien voorzien van een klikbare stacktrace, zodat je meteen kan navigeren naar de fout.
Selenium in JUnit
Als Fullstack-ontwikkelaar heb je met zowel de Frontend als de Backend te maken. Door de volwassen Frontend-technieken van tegenwoordig zit er ook volop logica in de Frontend. Logica die je ook moet testen.
Nu zijn daar wel frameworks voor (bijvoorbeeld Jasmine en Karma voor Angular), maar die werken lang niet altijd lekker
Het goede nieuws is dat er voortaan de mogelijkheid is om Frontend-(end-to-end/regressie)testen te maken in JUnit, met behulp van de Selenium WebDriver en Selenium Remote WebDriver.
Door de Selenium dependency toe te voegen, kun je de WebDriver API gebruiken vanuit JUnit. In de unit-testen roep je de WebDriver API aan, die de WebDriver aanstuurt om de acties in een daadwerkelijke browser uit te voeren.
Je kunt de WebDriver ook als headless browser draaien. Dit is een browser zonder GUI, wat het testen versnelt.
Voordat je de WebDriver API gebruikt, moet je eerst wat configuratie doen in de setup van de unit-test:
private WebDriver driver;
@BeforeClass
public static void prepareDriver() {
System.setProperty(“webdriver.chrome.driver”, PATH_TO_CHROME);
ChromeOptions chromeOptions = new ChromeOptions().addArguments(“--headless”);
driver = new ChromeDriver(chromeOptions);
}In de unit-testen wil je controleren of elementen op de webpagina aanwezig zijn, ze bepaalde tekst hebben, etc. Deze elementen vind je door middel van selectors. Er zijn verschillende selectors:
ID selector:
driver.findElement(By.id("contact"));CSS selector:
driver.findElement(By.cssSelector(".menu h3"));XPATH selector:
driver.findElement(By.xpath("//input"));Name selector: driver.
findElement(By.name("target"));Tag name selector:
driver.findElement(By.tagName("label"));Link tekst: driver.
findElement(By.linkText("Click here"));Met deze selectors kun je assertions doen op de gevonden elementen. Hieronder een voorbeeld om een homepage te controleren of de titel het woord “Home” bevat en er 3 menu-items zijn met een bepaalde tekst:
@Test
public void testHomePage() {
assertThat(driver.getTitle(), containsString(“Home”));
List<WebElement> menuItems = driver.findElements(By.cssSelector(“.menu h3”));
assertEquals(3, menuItems.size());
assertEquals(menuItems.get(0).getText(), “News”);
assertEquals(menuItems.get(1).getText(), “About”);
assertEquals(menuItems.get(2).getText(), “Contact”);
}Handig om bijvoorbeeld een regressietest mee te bouwen die elke pagina van de website afloopt om te controleren of bepaalde elementen aanwezig zijn, ter controle dat deze pagina nog steeds up and running is.
De dag van vertrek (verre van trek)
Op onze laatste dag hebben we eerst met een afvaardiging van NLJUG een bezoek gebracht aan Google. We wisten niet wat te verwachten, en het maakte eerlijk gezegd niet heel hongerig naar meer: we hebben voornamelijk kantines en cafetaria’s gezien 😉
Hoogste tijd om de koffers te pakken en weer naar huis te gaan. Waar we alweer uitkijken naar Oracle Code Two, of wordt het Oracle Code One, part II, in 2019?
Met plezier kijk ik terug op een fantastische week waarin veel is gelachen, veel kennis is opgedaan, en enthousiasme is aangewakkerd om nieuwe technieken te proberen. We kunnen er weer een jaar tegenaan!
