Automate Browsers With Playwright
After we got Playwright up and running in the last post, we can now take a closer look on how we can automate a web browser with Playwright.
After we got Playwright up and running in the last post, we can now take a closer look on how we can automate a web browser with Playwright.
Playwright is a reliable end-to-end testing framework for web applications. It is open-source and available for C#, Java, JavaScript, and Python. While it is similar to Selenium and Cypress, Playwright has its own twist on testing and offers a nice set of tools to make writing tests less tedious. Since Microsoft is putting a lot of resources into Playwright, I expect it to be around for the long haul.
In NUnit we can use the category attribute to classify tests. This allows us to mark long running tests and then tell our test runner to run them on demand but not with the regular test run. All we need to do is to add a category to a single test (or a class):
In a .Net Full Framework application we could use the property SpecifiedPickupDirectory in our mailSettings and the emails got stored to disk instead of sending them to the recipient. That allowed us to check them manually or in our test code.
For .Net 5 you should no longer use System.Net.Mail.SmtpClient and instead use MailKit. However, testing is a lot harder then MailKit does not offer such a convenient way to dump your emails to disk. Let us explore what we can do to check that our applications send the right emails.
If you persist a DateTime property to SQL Server you lose a tiny bit of precision. For most use cases this will go unnoticed. However, if you try to compare two objects as part of an integration test, your test will fail. Let us look how we can work around the different timer precisions between .Net and SQL Server in Fluent Assertions.
The more complex an application becomes, the greater is the benefit of Docker. If everything runs in containers, we can use a tool like docker-compose and start all the parts with one single command. No need to install all the tools, services, and frameworks - just run docker-compose and the magic happens automatically. We can go from nothing to the full running application in a few minutes.
Since I saw the talk "Dev and Test Agility for your Database with Docker" by Julie Lerman at NDC Oslo 2019 I wanted to port her solution for .Net Core to the .Net Full Framework. How hard could it be? As it turns out, it is an awful lot of work and a few weeks ago Microsoft made it even harder.
As we saw last week, parametrised tests help us to reduce the number of test methods we have to write and still keep the coverage high. However, writing the test parameters multiple times is error prone, especially when it is important that we test all values. Let us look on how NUnit can help us with this problem.
Parametrised tests help you to create many test cases without writing a lot of test methods. This approach saves you a lot of time and increases the quality of your tests. Let us look how we can parametrise our tests in NUnit.
Last week I attended the "Make Your Code More Testable" workshop by Ted M. Young (@jitterted). I was not sure if I wanted to attend yet another workshop this year as I saw the first tweet about this workshop. After I saw the recommendations by Gitte Klitgaard, Esther Derby, Kent Beck and GeePaw Hill I changed my mind, and I am happy I did.
Code katas are little exercises that help you to improve your programming skills. My favourite one is the Gilded Rose kata. It was originally created by Terry Hughes and is now maintained by Emily Bache (@emilybache).
While most katas start from scratch, the Gilded Rose kata comes with existing code that you need to modify. This code is available for more than 40 programming languages and covers most likely your favourite language.