C# 11: Een blik op 5 handige nieuwe functies

Blog

C# 11 is uit en biedt ontwikkelaars een aantal nieuwe functies en verbeteringen die de programmeertaal nog krachtiger maken. Van raw string literals tot pattern matching op Span<char> en ReadOnlySpan<char>, tot generic attributes en required modifiers, deze nieuwe functies maken het schrijven van software sneller, efficiënter en gemakkelijker. In dit artikel werpen we een blik op enkele van de belangrijkste nieuwe functies in C# 11 en hoe ze je kunnen helpen bij het schrijven van code. Dus, als je klaar bent om te ontdekken hoe C# 11 jouw code naar een hoger niveau kan tillen, lees dan verder!

Raw string literals

Raw string literals maakt het voor ontwikkelaars mogelijk om string literals te schrijven die meerdere regels kunnen beslaan en regeleinden en witruimte bevatten. Hierdoor is het gemakkelijker om strings op meerdere regels te schrijven zonder regeleinden te hoeven ‘escapen’. 

Pattern match Span<char> of  ReadOnlySpan<char> op een constant string

De nieuwe pattern matching functie in C# 11 maakt het mogelijk om te matchen op Span<char> of ReadOnlySpan<char> op een constant string. Hierdoor is het gemakkelijker om te werken met character arrays, vooral wanneer je bewerkingen zoals string vergelijking of substring-extractie moet uitvoeren.


 

List patterns

C# 11 introduceert ook list patterns, die het toelaten om op basis van specifieke kenmerken van een lijst te matchen. Dit maakt het gemakkelijker om bepaalde acties uit te voeren afhankelijk van de inhoud van de lijst.

Generic Attributes

C# 11 introduceert generic attributes, waarmee attributen gedefinieerd kunnen worden die met elk type, inclusief generieke types, kunnen worden gebruikt. Hierdoor is het gemakkelijker om herbruikbare en flexibele attributen te schrijven en informatie over types te verstrekken die door andere delen van uw code kunnen worden gebruikt.

Required Modifier

C# 11 introduceert het concept van required modifiers, waarmee aangeven kan worden dat bepaalde properties van een type door alle afgeleide types verplicht moeten worden geïmplementeerd. Dit is nuttig wanneer je er zeker van wilt zijn dat bepaalde leden altijd aanwezig zijn in alle afgeleide types, ongeacht hun implementatie.

Conclusie

C# 11 brengt een aantal handige nieuwe functies en verbeteringen met zich mee. Of je nu werkt met raw string literals, pattern matching op Span<char> of ReadOnlySpan<char>, generic attributes, required modifiers of list pattern, C# 11 maakt het ontwikkelen van software sneller, efficiënter en gemakkelijker. Upgrade nu naar C# 11 en ontdek de voordelen voor jezelf!

Marco
Auteur Marco Developer

Heb je vragen over dit onderwerp of zou je Marco willen inhuren voor een vergelijkbare opdracht?

Neem contact met ons op

Gerelateerde artikelen

Raymon Raymon / 21-03-2022

7 minuten lezen

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

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:

 

{
    "testFiles": "**/*.e2e.test.js",
    "chromeWebSecurity": false
}


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

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

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!

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?

  1. 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’);).
  2. Of een lijst 3 onderliggende elementen heeft ( cy.get(‘ul > li’).should(‘have.length’, 3); ).
  3. Controleren of een invoerveld of tekstgebied een bepaalde waarde heeft ( cy.get(‘input[name=“firstName”]’).type(‘Santa Claus’).should(‘have.value’, ‘Santa Claus’); ).

Bekijk deze lijst met voorbeelden van wat je kunt gebruiken in de should-method.

Extra voorbeeld:

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()
    })
  })
})


Kijk voor meer voorbeelden van de within()-method in de Cypress-documentatie.

Herbruikbare functionaliteit

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.

Michiel Michiel / 23-06-2022

3 minuten lezen

Vorige maand was alweer de zesde Tech Thursday die ik organiseerde en de tweede die ook toegankelijk is voor iedereen die geïnteresseerd is; waarom zouden we stoppen met delen bij de voordeur?

Terug naar het onderwerp van de laatste sessie: testen, testen en testen. Aan de titel van het blog kan je lezen dat er één keer testen afgevallen is. Waar ik het bij mijn presentatie over de drie bekendste frameworks had: MS-Test (v2), nUnit en xUnit, spits ik me nu toe tot twee andere interessante ontwikkelingen. Over bUnit heb ik toen ook al gesproken, maar aan het eind van mijn presentatie werd ik door een externe deelnemer gewezen op een andere package, Stryker Mutator.

bUnit

bUnit

Ik ga het echter eerst over bUnit hebben. Met bUnit kan je Blazor-componenten testen en het werkt altijd in combinatie met één van de andere drie testframeworks. Met bUnit is de Blazor-cirkel rond: van Back-End tot Front-End kan het geheel in C# opgezet worden, inclusief alle (unit)testen.

bUnit is dus bedoeld om een component te renderen en hier acties op uit te voeren en te testen of de output dan aan de verwachting voldoet. En dit kan meegenomen worden in een build pipeline.

Testen met bUnit kan in een normaal C# bestand (.cs) of in een Razor bestand (.razor).

Het voordeel van Razor bestanden is dat het volgende mogelijk is:

 

@inherits TestContext;

@code   
{

    [Fact]
    public void HelloWorldComponentRendersCorrectly()
    {
        var cut = RenderComponent<HelloWorld>();
        cut.MarkupMatches(@<h1>Hello world from Blazor</h1>);
    }
}


De markup kan dus gewoon door middel van het @ teken toegevoegd worden zonder allerlei andere escape tekens. Daarnaast negeert bUnit allerlei opmaak binnen HTML zoals tabs, spaties en enters.

Wil je echter gebruik maken van testen in Razor, dan is het handig om niet met het framework te beginnen (dus niet bijvoorbeeld een xUnit Test Project aanmaken), maar met een ASP.NET Core Empty project. Vervolgens voeg je de gebruikelijke NuGet packages toe om te testen.

Met C# 11 wordt het wellicht weer makkelijker om gewone C#-bestanden te gebruiken, omdat daar een interessante manier wordt geïntroduceerd die “raw string literals” heet .

 

var location = $$"""
   You are at {{{Longitude}}, {{Latitude}}}
   """;


 

Door drie quotes (of meer) te gebruiken, wordt een “raw string literal” gemaakt. Daarnaast heeft het aantal dollartekens aan hoeveel accolades er nodig zijn voor string interpolation.

Zoals het voorbeeld laat zien, is het niet gelijk aan bovenstaande code, maar hierdoor kan het gebruikt van C#-bestanden wel een overweging zijn.

Meer informatie over bUnit vind je hier.

Stryker Mutator

Stryker Mutator

Dat delen met iedereen een voordeel blijkt te hebben, geeft dit deel van de blog wel aan. Stryker was voor mij onbekend en deze interactie was precies waar ik naar zocht toen ik de Tech Thursday toegankelijk wilde maken voor iedereen.

Stryker Mutator is een project van InfoSupport met het doel om de kwaliteit van unit tests te verhogen. Stryker Mutator maakt aanpassingen aan je code waardoor er mutanten ontstaan. Goede unit tests zouden vervolgens moeten falen om gemuteerde code te ontdekken. Als (alle) unit tests slagen dan betekent dit dat de gewijzigde code niet afgedekt wordt door de unit tests.

Een simpel voorbeeld is de volgende code:



public bool IsAdult(int age)   
{
    return age >= 18;
}


 

Stryker zal deze code muteren door de code te wijzigen in:



public bool IsAdult(int age) 
{
    return age < 18;
}



 

Als je bovenstaande code test, dan krijg je nu een omgekeerd resultaat waardoor je test faalt en de mutant wordt uitgeschakeld.

In combinatie met een goede code coverage tool (zoals bijvoorbeeld SonarQube), is dit een waardevolle tool die ingezet kan worden bij Pull Requests: Stryker kan ingezet worden in build pipelines. Dan wordt niet alleen de code coverage gecontroleerd, maar ook de kwaliteit van de unit test.

Voor meer informatie over Stryker klik hier. Wijzigingen die Stryker Mutator allemaal kan doen, vind je hier en de NuGet package staat hier.

{description}

Heb je een .NET expert nodig?

Neem contact met ons op
{description}

Lees de blogs die onze experts geschreven hebben

Lees ze hier