Onze website bevat functionele en analytische cookies die nodig zijn om de website goed te laten functioneren
en jou als bezoeker een goede webervaring te geven. Deze statistieken worden volledig anoniem verwerkt. Meer
informatie is beschikbaar in onze privacyverklaring.
Om te beginnen: wat is end-to-end testen? We hebben twee zogeheten ‘ends’ in een webapplicatie: de Front-End en de Back-End. Met unit-testing testen we de code voor ofwel de Front-End ofwel de Back-End. We testen niet hoe de applicatie zich gedraagt in de browser of hoe beide ends samenwerken.
Begrijp me niet verkeerd: ik ben voorstander van unit tests! Maar het is net zo belangrijk om te testen hoe de Front-End en de Back-End samenwerken.
Met end-to-end testen kijk je of de Front-End goed samenwerkt met de Back-End. Zo moet bijvoorbeeld het automatisch invullen van formulieren worden getest met een end-to-end test, maar ook het klikken op knoppen en het navigeren door de pagina’s.
Deze end-to-end tests controleren dus of de Front-End de gegevens vanuit de Back-End correct verwerkt.
Wat is Cypress?
Er zijn veel end-to-end testtoolkits, maar een van de meest populaire en snelste toolkits is Cypress.
Cypress biedt een manier om end-to-end tests te schrijven met JavaScript en de testrunner. Daarnaast biedt het de mogelijkheid om screenshots en video’s op te slaan wanneer een test mislukt. En, waar de meeste organisaties blij van worden: het is open-source. En dat is geweldig.
End-to-end testen met Cypress
In de Cypress-documentatie staat een geweldige tutorial waarin je op weg wordt geholpen bij het schrijven van end-to-end-tests.
Stap 1: configureren
Aan de basis van het project bevindt zich een cypress.json, waar je enkele standaardconfiguraties kunt wijzigen. In ons project ziet het er als volgt uit:
In de property testFiles vertellen we Cypress om te zoeken naar bestanden die e2e.test.js in de naam bevatten. Je kunt Cypress configureren met TypeScript, maar in dit geval denk ik dat dat geen toegevoegde waarde heeft. Het vereist een extra transpilatie-stap die langer duurt.
Stap 2: testbestanden opslaan
Bij unit-testing is het heel gebruikelijk om de tests op te slaan in de componentmappen. In dit geval neemt Cypress de map cypress/integration als root om naar de bestanden te zoeken. We hebben dus een structuur die gebaseerd is op de applicatie zelf, waarin we de end-to-end testbestanden opslaan.
Stap 3: de test voorzien van minimale eisen
Elke test heeft ten minste een function describe() met daarin ten minste één it() function. Dit werkt op dezelfde manier als het schrijven van unit-tests:
describe('My First Test', () => {
it('Does not do much!', () => {
expect(true).to.equal(true)
})
})
Dit voorbeeld lijkt op een unit-test. We moeten dus gebruik maken van de Cypress Library. Je kunt dat gebruiken door cy te gebruiken zoals in het onderstaande voorbeeld, waarin we https://example.cypress.io bezoeken.
describe('My First Test', () => {
it('Visits the Kitchen Sink', () => {
cy.visit('https://example.cypress.io')
})
})
Je kunt zien dat de echte browser deze actie uitvoert door npm run e2e:open uit te voeren.
Onze scripts in de package.json zien er als volgt uit:
{
//...
"e2e:run": "npx cypress run --config-file cypress.json",
"e2e:open": "npx cypress open --config-file cypress.json",
"e2e:open:edge": "npx cypress open --browser edge --config-file cypress.json",
"e2e:open:firefox": "npx cypress open --browser firefox --config-file cypress.json"
//...
}
Cypress start de toepassing en daar kan je de end-to-end-test selecteren die je wilt uitvoeren. Standaard wordt de Chrome-browser geopend, maar er is ook een optie om het in Firefox of Edge uit te voeren.
Cypress biedt een complete bibliotheek en je kunt de documentatie raadplegen voor meer informatie hierover.
Stap 4: testen!
We zullen vooral zaken die in de browser verschijnen of veranderen testen met end-to-end tests. Een eenvoudig scenario: we bezoeken pagina x en controleren of de h1 de tekst “Dit is een geweldige titel” bevat.
describe('My First Test', () => {
it('Visits the Kitchen Sink', () => {
cy.visit('https://example.cypress.io');
cy.get('h1').should('contain.text', ' Dit is een geweldige titel');
})
})
In dit voorbeeld maakt elke methode die je aanroept vanuit de cy-bibliotheek deel uit van het testen. Zo zal cy.visit() de actie uitvoeren, maar als er geen geldige pagina op die URL staat, zal de test niet slagen. Dus met elke actie die je uitvoert, begin je een ‘assertion’.
In Cypress zijn er twee verschillende soorten ‘assertions’. should() of and() zijn “Implicit Subjects”. .expect is een “Explicit Subject”. Lees hier meer over in de Cypress-documentatie.
Bij het aanroepen van cy.get(‘h1’) zal het zoeken naar de H1-tag. Wanneer het dat element vindt, gaat de test verder. De test zal falen indien het element niet binnen een paar milliseconden wordt gevonden. Na de get-method kun je een heleboel andere methoden koppelen, zoals:
.contains() verwacht dat het element met inhoud uiteindelijk in de DOM zal bestaan.
.find() verwacht ook dat het element uiteindelijk in de DOM zal bestaan.
.type() verwacht dat het element uiteindelijk in een typbare staat zal zijn.
.click() verwacht dat het element zich uiteindelijk in een bruikbare staat bevindt.
.its() verwacht uiteindelijk een property over het huidige onderwerp te vinden.
Dus wat testen we met end-to-end-tests?
Of een element een bepaalde klasse heeft (cy.get(‘element.selector’).should(‘have.class’, ‘ng-valid’); ) of juist niet (cy.get(‘element.selector’).should(‘not.have.class’, ‘ng-valid’);).
Of een lijst 3 onderliggende elementen heeft ( cy.get(‘ul > li’).should(‘have.length’, 3); ).
Controleren of een invoerveld of tekstgebied een bepaalde waarde heeft ( cy.get(‘input[name=“firstName”]’).type(‘Santa Claus’).should(‘have.value’, ‘Santa Claus’); ).
Je kunt de context van een bovenliggend element toevoegen om assertions uit te voeren, wat handig is bij formulieren.
<form>
<input name="email" type="email" />
<input name="password" type="password" />
<button type="submit">Login</button>
</form>
describe('My First Test', () => {
it('Visits the Kitchen Sink', () => {
cy.visit('https://example.cypress.io');
cy.get('form').within(($form) => {
// you have access to the found form via
// the jQuery object $form if you need it
// cy.get() will only search for elements within form,
// not within the entire document
cy.get('input[name="email"]').type('john.doe@email.com')
cy.get('input[name="password"]').type('password')
cy.root().submit()
})
})
})
In het geval van herbruikbare acties die je keer op keer uitvoert, kan je eenvoudige functies schrijven die je in een lib-map kunt plaatsen. Maar Cypress biedt een gebruiksvriendelijkere manier om dit te doen. Dit wordt “custom commands” genoemd; hiervan kan je veel voorbeelden vinden in de documentatie.
Maar een van de beste voorbeelden is het schrijven van de command voor de login. Je moet die code toevoegen aan het bestand cypress/support/commands.js.
Cypress.Commands.add('login', (userType, options = {}) => {
// this is an example of skipping your UI and logging in programmatically
// setup some basic types
// and user properties
const types = {
admin: {
name: 'Jane Lane',
admin: true,
},
user: {
name: 'Jim Bob',
admin: false,
},
}
// grab the user
const user = types[userType]
// create the user first in the DB
cy.request({
url: '/seed/users', // assuming you've exposed a seeds route
method: 'POST',
body: user,
})
.its('body')
.then((body) => {
// assuming the server sends back the user details
// including a randomly generated password
//
// we can now login as this newly created user
cy.request({
url: '/login',
method: 'POST',
body: {
email: body.email,
password: body.password,
},
})
})
})
Conclusie
Nu is het aan jou om geweldige end-to-end tests te schrijven met Cypress! Perfecte tests bestaan niet, maar als je ze elke keer een beetje optimaliseert, wordt het je ‘source of truth’. De end-to-end-tests zijn geweldig voor developers om uit te voeren na het bouwen van een nieuwe functie of het wijzigen van een bestaande, omdat het onmogelijk is om alle testscenario’s te onthouden.
Veel succes en plezier met het schrijven van waardevolle end-to-end tests! Als we je hierbij kunnen helpen, doen mijn collega’s en ik dat natuurlijk graag.
Deel deze pagina:
Auteur
Raymon
Developer
Heb je vragen over dit onderwerp of zou je Raymon willen inhuren voor een vergelijkbare opdracht?
Front-End developers weten dat de ontwikkeling van Front-End technieken nooit stil staat. De ontwikkeling van frameworks als React, Vue, Angular en Svelte is de laatste jaren flink gegroeid. Daarnaast komen er steeds vaker handige tools beschikbaar die het leven van een frontender net iets makkelijker kunnen maken. Deze keer kijken we naar Storybook en wat de meerwaarde hiervan kan zijn zowel voor een developer als voor andere disciplines. In eerste plaats moeten we weten wat Storybook is, en waar het voor gebruikt kan worden.
Wat is Storybook?
Het maken en onderhouden van een style guide is over het algemeen een uitdaging. Storybook is een open source framework dat het eenvoudiger maakt om de user interface van projecten te bouwen, documenteren, testen en demonstreren.
Storybook kan gebruikt worden als playground voor UI componenten. Doordat Storybook zelf buiten de applicatie draait, kunnen we het gedrag van de componenten in Storybook aanpassen naar een gewenste situatie, zonder dat dit invloed heeft op de componenten in de applicatie.
De huidige versies van Storybook ondersteunen functionaliteiten die een groot aantal onduidelijkheden in de moderne workflow voor webontwikkeling opvult.
Storybook ondersteunt de meest gangbare Front-End frameworks van het moment zoals React, Vue en Angular, maar is ook vanuit native JavaScript te gebruiken.
Wat is de story van Storybook?
Uit de behoefte om componenten in een geïsoleerde omgeving te kunnen definiëren, developen en de UI te kunnen testen, begon Storybook in april 2016 met een eerste release van versie 1.0 vanuit de Kadira startup (de originele developer van Storybook), waarna in september van het zelfde jaar versie 2.0 vrijgegeven werd.
Na dat de startup werd stopgezet en het project dood werd verklaard, volgde er een korte break en werd het project in 2017 door de open source verder omarmd. Inmiddels is versie 6.3 gereleased (juni 2021). De hele storybook story is te vinden op https://storybook.js.org/blog/the-storybook-story/
Storybook stopgezet door Kadira
Ondertussen hebben ze meer dan 10.000 github stars en 290k maandelijkse downloads.
Wie kunnen Storybook gebruiken en hoe?
Developers binnen het team zullen Storybook gebruiken als werkruimte om componenten op dezelfde manier neer te zetten. Een voordeel is dan ook dat de opgedane kennis van Storybook te gebruiken is bij elk framework dat momenteel door Storybook ondersteunt wordt.
Storybook kan opengesteld worden voor externe developers, wat interessant kan zijn voor open source ontwikkeling. Hiervoor kan Storybook vooral ingezet worden als documentatie waarbij de API van de componenten wordt uitgelegd.
Voor UX/UI designers kan Storybook als onderdeel dienen van hun design system met koppelingen naar o.a. Frontify waardoor het als gemeenschappelijk bron kan dienen. Als er aanpassingen gedaan moeten worden of er een nieuw component ontwikkeld is, hebben ze gelijk alle (nieuwe) componenten tot hun beschikking
Naast dat het documentatie oplevert, heeft het nog een voordeel dat de stakeholders sneller een nieuwe component kunnen beoordelen op het design en functionaliteit en niet afhankelijk zijn van een nieuwe release. Ook kan Storybook gebruikt worden voor verdere communicatie binnen of buiten het bedrijf.
Om Storybook te gebruiken binnen een project, moet er wel rekening gehouden worden met het gekozen framework van het project. Zo zal de installatie en de structuur/syntax voor React net iets even anders zijn dan voor bijvoorbeeld Vue of Angular.
Storybook is gebaseerd op componenten: maak daarom componenten zo compact mogelijk. Terwijl een project groeit met steeds meer componenten, is het verstandig om de volgende richtlijnen te hanteren:
Je codeert de stories in Storybook om een component weer te geven, maar het kan ook op zichzelf documentatie worden over hoe het component te implementeren is.
Heldere en duidelijke code. Het doel is om te begrijpen hoe je het component kunt gebruiken zonder te veel na te denken.
Om dit te doen, probeer zo statisch mogelijk te zijn: vermijd abstracties, herhaal indien nodig, vermijd elk soort algoritme.
Een juiste benaming en locatie van je story, zodat deze overeenkomt met je codebase
Op het eerste gezicht lijkt Storybook alleen te zijn bedoeld voor zo gezegd ‘domme componenten’ die alleen gebruikt worden voor de user interface. Door de complexere componenten te isoleren en business logica te verminderen, kunnen deze echter prima binnen Storybook gebruikt worden waarbij de focus verlegd wordt van de functionaliteit naar het component zelf.
Storybook addons
In de basis is Storybook vrij compleet, maar dat wil niet zeggen dat we er niet meer mee kunnen doen. Daarom zijn er tal van addon’s voor te vinden die net even dat stukje extra functionaliteit kunnen geven.
Populaire addons
Een aantal veel gebruikte addons zijn:
Links - dit kan gebruikt worden om componenten onderling te verbinden om demo’s of prototypes mee te maken.
Viewport - met Storybook Viewport Addon kunnen jouw verhalen in Storybook in verschillende formaten en lay-outs worden weergegeven. Dit helpt bij het bouwen van responsieve componenten in Storybook.
Actions – geeft data weer in de UI na het uitvoeren van een event handler
Accessibillty - test je componenten tegen de huidige webstandaard
Docs – standaard heeft elke story al een DocsPage. Mocht deze niet voldoende zijn kan er gebruik gemaakt worden van deze addon waarna er meer mogelijkheden zijn voor documentatie
Conclusie
Storybook kan optimaal functioneren als het gebruikt wordt door developers, UX/UI developers en de stakeholders. Door combinatie van deze verschillende disciplines levert Storybook een grote meerwaarde voor het ontwikkelen en het onderhouden van webapplicaties.
Zelf aan de slag?
Wil je zelf aan de slag met Storybook, maar kan jouw team wel iemand gebruiken die hier ervaring mee heeft? Mijn mede-frontenders bij ShareValue en ikzelf hebben hier ervaring mee, werken graag met Storybook en komen dan ook graag jouw team helpen bij het opzetten hiervan.
Het Front-End landschap is breed en divers. Er zijn veel technieken, frameworks en methoden om je doel te bereiken. En kies je dan voor grote namen als React, Angular en Vue (de drie grote frameworks van de laatste jaren). Of kijk je ook verder naar nieuwere spelers?
Svelte is zo’n nieuwere speler en begint inmiddels aardig in te lopen, als het gaat om naamsbekendheid en vooral op Developer Experience.
Daarom zoom ik in op Svelte en kijk ik naar de mogelijkheden die dit framework biedt, hoe je het gebruikt en wat SvelteKit precies is.
Het begin
Svelte is gemaakt door Rich Harris, die toentertijd werkte als onderzoekjournalist bij de New York Times. De stukken die hij schreef wilde hij graag kunnen voorzien van interactieve visuals zoals tabellen, grafieken, infographics. Eerst probeerde hij dit te maken met bestaande frameworks, maar dat sloot niet aan bij zijn manier van werken. Dus maakte hij een eigen framework.
Wat maakt Svelte interessant?
Svelte is heel anders in opzet dan bijvoorbeeld React of Angular. Het lijkt eerder op Vue, maar dan nog eenvoudiger. Net zoals bij Vue, maak je gebruik van één bestand voor de styling, de structuur en de logica. Alleen gebruik je bij Vue een .vue bestand, en bij Svelte een .svelte bestand.
Nu is dat niet zo schokkend, maar interessanter is dat Svelte duidelijk andere keuzes maakt dan de drie grote namen. Svelte is zo licht en compact dat het tijdens ontwikkelen een build kan doen in compile-time. Dat betekent dat andere frameworks nog een apart build-proces moeten doorlopen terwijl Svelte direct te gebruiken is. En alles wat niet gebruikt wordt uit het framework, wordt er netjes uitgelaten. Dit wordt tree-shaking genoemd. Andere frameworks doen dit ook, maar Svelte gaat hier zo ver in, dat Svelte code helemaal verdwijnt…
Het unieke van Svelte; het verdwijnt…
Bij veel andere frameworks dient er altijd nog een import te worden gedaan van het framework zelf. In het geval van Svelte is dat niet het geval. De gegeneerde code is alles wat je nodig hebt.
Als we kijken naar het onderstaande codeblock, dan zien we Svelte code waarin een variabele wordt gedefinieerd (genaamd “count”) met een waarde 0. Onderaan zien we de template voor een button, met een on:click handler. Elke keer als er op de button geklikt wordt, wordt “count” verhoogd met 1. Dan zien we iets bijzonders. Op regel 4 staat een $:. Dit betekent dat Svelte dit block aan het watchen is. Dit wordt een Reactive Statement genoemd.
Zodra dit if block true is, is wordt het direct uitgevoerd. In dit geval geeft de browser een waarschuwing, dat “count” nu wel heel hoog wordt.
<script>
let count = 0;
$: if (count >= 10) {
alert(`count is dangerously high!`);
count = 9;
}
function handleClick() {
count += 1;
}
</script>
<button on:click={handleClick}>
Clicked {count} {count === 1 ? 'time' : 'times'}
</button>
Natuurlijk is dit geen 🚀-science, maar vooral het feit dat het zo weinig regels code nodig zijn om dit te bereiken vind ik toch een aardige prestatie. Evenals de Reactive statement: het is geen functie die moet worden afgetrapt; het gebeurt gewoon.
Sveltekit (Svelte + SSR + Routing + nog veel meer)
Naast Svelte als JavaScript framework, is er ook SvelteKit. Dit is meer in lijn met een framework als Nextjs of Nuxt. Oorspronkelijk werd dit in de bèta fase gelanceerd onder de naam Sapper. Sveltekit is nu net uit bèta en biedt Svelte als basis met nog veel meer extra’s zoals Server Side Rendering (SSR) en Routing (de routering van de pagina’s van een website of applicatie). Ook is het mogelijk om Progressive Web Apps te maken met Sveltekit, doordat het slim om kan gaan met caching en ondersteuning voor offline gebruik.
Conclusie; Svelte Zeker de moeite waard
Svelte heeft de laatste jaren een vlucht genomen en is een goede speler geworden binnen het JavaScript landschap. Dit komt ook zeker terug in onderzoeken onder developers. Zo werd het verkozen tot het meest prettige framework om mee te werken in de State of JS 2020 (State of JS 2020: Front-end Frameworks).
Wil jij ook aan de slag met Svelte? Onze Front-End developers gaan hier graag samen met jou mee aan de slag. Neem vooral eens vrijblijvend contact op om de mogelijkheden te bespreken.
Door de COVID-lockdown werken bijna alle developers vanuit huis. Hoewel we veel communicatiemiddelen hebben om met elkaar in contact te blijven, ging het samen programmeren (“pair programming”) toch niet zo soepel als ik zou willen.
Voor niet-ingewijden: pair programming is de werkwijze in softwareontwikkeling waarbij twee ontwikkelaars achter een enkele computer aan een stuk code werken. We doen dit omdat we vaak betere oplossingen bedenken wanneer gezamenlijk verschillende opties bespreken en uitproberen. Door deze uitwisseling van ideeën verbeteren we niet alleen de kwaliteit van code, maar ook de interpersoonlijke dynamiek. Én we investeren we in betere kennisdeling.
Afgezien van pair programming, vragen professionele ontwikkelaars ook vaak anderen om feedback of een beetje ondersteuning als ze ergens mee bezig zijn waar ze minder bekend mee zijn. In een kantooromgeving zou je af en toe een collega vragen om over je schouder mee te kijken en te helpen een stukje code te analyseren waar je moeite mee hebt. Vaak kunnen collega’s dan de hiaten in je kennis opvullen of helpen om op een nieuwe manier over het probleem na te denken. Andere keren helpt alleen al het uitleggen van het probleem me om een stap terug te doen en het probleem anders te bekijken (ook bekend als Rubber Duck Debugging).
Als je bij elkaar op kantoor zit, werkt dit uitstekend. Op afstand was dit een uitdaging. De standaard communicatiemiddelen hebben allemaal hun voor- en nadelen:
E-mail
Chatten
Telefoon
Videobellen
E-mail
E-mail is geweldig voor het verzenden van hele brieven waarin een bepaald probleem wordt beschreven. Het maakt het ook mogelijk om documenten bij te voegen; of het nu screenshots of stukjes code zijn. Discussies kunnen van een thread worden voorzien om gerelateerde communicatie bij te houden zodat je gemakkelijk kunt terugzoeken. Het grootste nadeel van e-mailen is echter dat het even kan duren voordat je antwoord krijgt: je bent afhankelijk van een antwoord van de ontvanger wanneer het hem of haar uitkomt. Ik heb bijvoorbeeld mijn e-mailclient niet de hele tijd open: ik check mijn mail maar twee of drie keer per dag, zodat ik me kan concentreren op het programmeren in Visual Studio. Een heel verhaal typen om je probleem uit te leggen kan soms ook lastig zijn, vooral wanneer de code voortdurend evolueert en de bijgevoegde code mogelijk niet eens werkt tegen de tijd dat de ontvanger er naar kijkt.
Chatten
Als alternatief voor e-mail kunnen teamgenoten door te chatten via Slack, Microsoft Teams of vergelijkbare apps sneller verbinding met elkaar maken. De communicatie is direct en men kan op dezelfde manier documenten met elkaar delen. De toevoeging van aanwezigheidsindicatoren (groen = beschikbaar, geel = afwezig, rood = bezet) zoals in Microsoft Teams helpt de communicatie te vergemakkelijken zonder elkaar te veel te storen. Net als bij e-mail is het echter niet eenvoudig om je probleem volledig te communiceren, maar de onmiddellijke reactie kan helpen om het sneller te beperken.
Bellen
Soms is het beter om gewoon te bellen. Met een eenvoudig telefoongesprek kun je vrijer praten en vaak is het ook sneller en efficiënter dan wanneer je alles moet uittypen Het nadeel is natuurlijk dat beide partijen niet hetzelfde referentiekader hebben: beide partijen zouden elkaar moeten vertellen waar de code of een paragraaf in een document te vinden is. Wij merken dat we meestal toevlucht nemen tot het delen van de documenten of screenshots via een chat of e-mail om tijdens het telefoongesprek te illustreren waar we het over hebben.
Videobellen
Gelukkig combineert videobellen zoals met Microsoft Teams veel van de voordelen van de bovenstaande vormen van communicatie. Men kan zijn computerscherm delen (en zelfs de controle over je scherm doorgeven aan de collega), een spraak- en videogesprek voeren en de nodige bestanden delen. Toch heeft ook deze vorm van communicatie zijn grenzen. Ten eerste leent de kwaliteit van de verbinding zich niet altijd voor een videokwaliteit die fatsoenlijk genoeg is om gedetailleerde tekst zoals code te verzenden. Een ander probleem dat men kan tegenkomen is dat wanneer een partij een hoge resolutie heeft zoals een 4K- of WQHD-scherm en deze deelt met iemand die op een HD 15” laptopscherm werkt de tekst ook onleesbaar wordt. Ten slotte, wanneer ontwikkelaars hun Visual Studio met beheerdersrechten draaien (bijvoorbeeld bij het debuggen van een door IIS gehoste oplossing), kan de andere partij de controle niet overnemen. Navigeren door de call-stack of het zetten van breakpoints of watches zijn dan moeilijker te coördineren.
Was er maar een betere manier…
Tools voor samenwerken op afstand bestonden natuurlijk al. Velen van ons zijn gewend geraakt aan Google Docs, Microsoft 365 en SharePoint. Meerdere mensen kunnen dan tegelijkertijd een document als een spreadsheet bewerken. Alleen de gegevens werden onderling gedeeld, hun schermindelingen zijn van henzelf.
Figuur: meerdere mensen die tegelijkertijd aan een Google Sheets-document werken
En daar is de LiveShare-extensie van Microsoft voor Visual Studio
In 2019 bracht het Visual Studio Code-team een uitbreiding uit op de platformonafhankelijke IDE, waarmee ontwikkelaars hun ontwikkelervaring rechtstreeks via internet konden delen. Het werd al snel standaard geïnstalleerd in VS Code en als een optionele download voor gebruikers van Visual Studio voor Windows 2017. We gingen er meteen mee aan de slag, experimenteerden ermee en moedigden teamgenoten aan om het ook te gebruiken. De enige uitdaging was het overtuigen van deze teamgenoten om nóg een extensie voor Visual Studio te installeren. We waren dan ook blij dat bij de lancering van Visual Studio voor Windows 2019 de LiveShare-extensie standaard al meegeleverd werd.
Visual Studio Live Share
De extensie heeft een aantal geweldige functies:
Live bewerken:Schrijf en bewerk code samen in realtime
Focus en volg: Vestig de aandacht op uw cursor of volg anderen wanneer zij navigeren
Geïntegreerde audiogesprekken: Communiceer met anderen via spraak vanuit de IDE
Groepsfoutopsporing: Stel breakpoints in en loop samen door de code
Gedeelde servers: Web-apps en databases bekijken zonder poorten bloot te stellen aan het internet
Gedeelde terminal: Voer commando’s en taken uit, waarbij de uitvoer naar teamleden wordt gestreamd
Gestreamde ervaring: De IDE-ervaring wordt gestreamd, genodigden hebben geen kopie van de code nodig
Toen Nederland in maart 2020 in lockdown ging en alle kantoren werden gesloten, heeft onze collega eindelijk van de gelegenheid gebruik gemaakt om zijn team te overtuigen om LiveShare te proberen. Het bleek een geweldige match te zijn. Het stelde hen in staat om effectiever te zijn in de communicatie: ze waren veel productiever!
Ze konden naar dezelfde code kijken, terwijl ze onze eigen schermresolutie of kleurenschema gebruikten, samen debuggen en de werking van de code inspecteren terwijl deze werd uitgevoerd.
Vooral in gevallen waarin onze collega vastzat op een stukje code en een collega nodig had om virtueel over zijn schouder mee te kijken, was de LiveShare-extensie een zegen. Hij kon zijn applicatie lokaal uitvoeren, een breakpoint instellen en bespreken wat de applicatie aan het doen was terwijl hij hem zag draaien. Zijn teamgenoot kon dan de “stack trace” manipuleren, een “watch” instellen, enz. om het probleem te diagnosticeren of te helpen nadenken over het probleem. Gesprekken die vroeger 30 minuten of langer duurden, duurden nu minder dan 10. Iedereen kon sneller terug naar de eigen werkzaamheden zonder hun respectievelijke Visual Studio-ontwikkelomgevingen te verlaten.
Veel gebruiksscenario’s
Het belangrijkste voordeel van het gebruik van Visual Studio LiveShare is voor ons dat de ontwikkelaars in hun belangrijkste tool kunnen blijven: je hoef Visual Studio nooit te verlaten. Als je het veel afleiding hebt, sluit je Microsoft Outlook en Teams af om je op code te concentreren.
Met LiveShare als extensie in zijn Visual Studio-omgeving kan onze collega gemakkelijk een collega uitnodigen om hem te helpen, of hij kan snel reageren als zij een vraag aan mij hebben.
LiveShare zorgt voor zo’n rijke samenwerkingservaring dat je het ook kunt gebruiken voor een verscheidenheid aan code-werkzaamheden:
Realtime pair programming op afstand: Gezamenlijk programmeren en/of code-analyse
Code reviews: Op afstand code lezen en bespreken
Technisch sollicitatiegesprek: Kijk hoe een kandidaat een technische taak voltooit in hun IDE en bespreek hun aanpak
Code-bootcamps: Presenteer voorbeeldoplossingen aan de deelnemers, navigeer door code en toon werkende applicaties
Technische workshops: Laat een workshopdocent virtueel over de schouder meekijken en cursisten verder op weg helpen
Zoals je misschien al geraden hebt, zijn wij fan van deze tool. Het heeft onze collega in staat gesteld om effectiever samen te werken met zijn teamgenoten en heeft ook geholpen om met de gedeelde kennis van de code van ons project te verbeteren.
Nu de extensie is ingebouwd in zowel Visual Studio Code als Visual Studio voor Windows 2019, is er geen beter moment dan nu om te zien hoe het je ontwikkelteam kan helpen om op afstand samen te werken! En mochten wij je kunnen helpen bij het inzetten van deze tool en/of het uitrollen ervan, dan horen we het natuurlijk graag. Onze .NET experts staan er klaar voor!