<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>UnitTest - Tag - AWS Sensei</title><link>https://aws-sensei.cloud/tags/unittest/</link><description>UnitTest - Tag - AWS Sensei</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 06 May 2021 00:00:00 +0200</lastBuildDate><atom:link href="https://aws-sensei.cloud/tags/unittest/" rel="self" type="application/rss+xml"/><item><title>Fake Methods and Dependencies without Dependency Injection</title><link>https://aws-sensei.cloud/posts/2021-05-06-overridable-members/</link><pubDate>Thu, 06 May 2021 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2021-05-06-overridable-members/</guid><description>🔊 Voiced by Amazon Polly
Mocking via virtual method Fake Dependencies with an Interface and Dependency Injection is easy and the usual approach. But how can you fake without Dependency Injection or an Interface. I will show you two situations that came up in production code.
Factory Method The first situation is a small AWS Lambda function with an http call. We want to mock the .Net HttpClient and write a UnitTest for our Request method.</description></item><item><title>Fake static property DateTime.Now() with a DateTime Provider</title><link>https://aws-sensei.cloud/posts/2021-05-04-datetime-provider/</link><pubDate>Tue, 04 May 2021 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2021-05-04-datetime-provider/</guid><description>🔊 Voiced by Amazon Polly
Our code is often time-dependent. We use the date or time to implement logic and make decisions in our code. The behavior of DateTime.Now or DateTime.UtcNow can differ due to the system, timezone and the time change (summer/winter). This means that we have to control this for our tests.
Take this method for instance:
public double ReturnCurrentOffset() { var result = DateTime.Now - DateTime.UtcNow; return result.</description></item><item><title>Share context between tests with fixtures</title><link>https://aws-sensei.cloud/posts/2021-05-02-test-fixture-pattern/</link><pubDate>Sun, 02 May 2021 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2021-05-02-test-fixture-pattern/</guid><description>🔊 Voiced by Amazon Polly
Test Fixtures Imagine your about to sit down to eat your lunch. The dirty breakfast dish is still on the table. You got three options. You can get a new plate, you can clean the old plate, or you can just eat lunch off the dirty plate. Thats it. New plate, clean plate, dirty plate. The same rules apply to tests.
Transient Fresh Fixture Getting a new plate is what Meszaros calls in the book &amp;ldquo;XUnit Test Patterns&amp;rdquo; a Transient Fresh Fixture.</description></item><item><title>Create Test Data cleanly with Fluent Builder Pattern</title><link>https://aws-sensei.cloud/posts/2021-05-01-fluent-builder-pattern/</link><pubDate>Sat, 01 May 2021 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2021-05-01-fluent-builder-pattern/</guid><description>🔊 Voiced by Amazon Polly
Helper methods make it easier to create test data. But they can become difficult to read over time as you need more variations of the test data to satisfy constantly evolving requirements from new tests.
Let say, we have the following Customer class.
public class Customer { public string Name { get; set; } public DateTime? DateOfBirth { get; set; } public string Email { get; set; } public string Address { get; set; } } In generally we create an instance of the Customer and set the respective properties as shown below.</description></item></channel></rss>