# Monday, July 12, 2021

Episode 670

Jason Bock on Mutation Testing

Mutation Testing involves modifying code that should break tests in order to validate the quality of these tests. Tools like Stryker allow you to do this automatically. Jason Bock discusses how this fits into your testing strategy.


Monday, July 12, 2021 9:52:00 AM (GMT Daylight Time, UTC+01:00)
# Thursday, July 1, 2021

GCast 113:

Passing parameters to xUnit net tests with the ClassData attribute

The [ClassData] attribute of xUnit.net allows you to store a collection of data parameters in a single class and pass that class to a single test method, allowing it to run multiple tests with different values.

You can find the source  code at https://github.com/DavidGiard/XUnitDemo

Thursday, July 1, 2021 4:13:31 PM (GMT Daylight Time, UTC+01:00)
# Thursday, June 24, 2021

GCast 112:

Passing parameters to xUnit.net tests with the InlineData attribute [GCAST 112 ]

If you have multiple unit tests with redundant code, it may make sense to create a single test and pass parameters to it. You can do this using the [InlineData] attribute of xUnit.net.

You can find the source code at https://github.com/DavidGiard/XUnitDemo

Thursday, June 24, 2021 9:19:00 AM (GMT Daylight Time, UTC+01:00)
# Thursday, June 17, 2021

GCast 111:

Writing unit tests with xUnit.net

Learn how to use the xUnit.net open source project to create unit tests for your .NET application You can find the source code at https://github.com/DavidGiard/XUnitDemo

Thursday, June 17, 2021 9:04:00 AM (GMT Daylight Time, UTC+01:00)
# Monday, December 28, 2020

Episode 641

Ed Charbeneau on Blazor Testing

Microsoft Blazor presents some challenges for those creating automated tests. Ed Charbeneau describes ways to address these challenges and some tools to help you create unit tests and functional tests.


Monday, December 28, 2020 9:43:00 AM (GMT Standard Time, UTC+00:00)
# Thursday, May 21, 2020

GCast 85:

Dependency Injection in Java Spring Apps

Learn how to declarative initialize services using the dependency injection features of the Java Spring framework.

GCast | Java | Testing | Video
Thursday, May 21, 2020 1:37:26 PM (GMT Daylight Time, UTC+01:00)
# Monday, April 27, 2020

Episode 606

Layla Porter on Test Driven Development

Twilio Senior Developer Evangelist Layla Porter discusses Test-Driven Development and how you can use it to improve your code.




Monday, April 27, 2020 9:28:00 AM (GMT Daylight Time, UTC+01:00)
# Monday, February 18, 2019

Episode 551

Jeremy Miller on Automated Testing in .NET Core

Jeremy Miller describes how testing ASP.NET applications is simpler with ASP.NET Core. He discusses the modularity of .NET, the lack of dependencies on IIS, and his open source testing project Alba.

Monday, February 18, 2019 9:21:00 AM (GMT Standard Time, UTC+00:00)
# Monday, February 4, 2019

Episode 548

Jennifer Wadella on Gatsby

Jennifer Wadella describes how to use the Gatsby tool to quickly create static web sites.

Monday, February 4, 2019 9:07:00 AM (GMT Standard Time, UTC+00:00)
# Monday, July 10, 2017
Monday, July 10, 2017 3:58:31 PM (GMT Daylight Time, UTC+01:00)
# Monday, December 28, 2015
Testing | Web
Monday, December 28, 2015 11:16:22 PM (GMT Standard Time, UTC+00:00)
# Monday, May 19, 2014
Monday, May 19, 2014 11:02:00 AM (GMT Daylight Time, UTC+01:00)
# Tuesday, September 24, 2013
Tuesday, September 24, 2013 1:24:59 AM (GMT Daylight Time, UTC+01:00)
# Monday, March 4, 2013
Monday, March 4, 2013 5:53:08 AM (GMT Standard Time, UTC+00:00)
# Friday, November 2, 2012
Friday, November 2, 2012 2:43:59 PM (GMT Standard Time, UTC+00:00)
# Thursday, November 1, 2012

This screencast demonstrates how to change a Visual Studio 2012 Coded UI Test after you have recorded it.

Thursday, November 1, 2012 2:28:00 PM (GMT Standard Time, UTC+00:00)
# Wednesday, October 31, 2012

This screencast shows how to add assertions to a Visual Studio 2012 Coded UI Test while recording your mouse and keyboard actions.

Wednesday, October 31, 2012 2:26:00 PM (GMT Standard Time, UTC+00:00)
# Tuesday, October 30, 2012

This screencast covers the fundamentals of Microsoft Coded UI Tests, a feature of Visual Studio 2012, Premium and Ultimate Editions. You will learn how to record mouse and keyboard actions to record a simple "smoke test".

Tuesday, October 30, 2012 2:25:00 PM (GMT Standard Time, UTC+00:00)
# Sunday, October 28, 2012
Sunday, October 28, 2012 2:11:00 PM (GMT Standard Time, UTC+00:00)
# Saturday, October 27, 2012

This screencast demonstrates how to change a Visual Studio 2010 Coded UI Test after you have recorded it.

Saturday, October 27, 2012 3:22:00 PM (GMT Daylight Time, UTC+01:00)
# Friday, October 26, 2012

This screencast shows how to add assertions to a Coded UI Test while recording your mouse and keyboard actions.

Friday, October 26, 2012 3:19:00 PM (GMT Daylight Time, UTC+01:00)
# Tuesday, July 24, 2012

Functional testing, system testing, and acceptance testing of software often involves manual actions by a user. To verify that an application works as designed, a user launches the application, navigates to a specific module, enters some data, and verifies the expected output.

Such testing tends to be expensive in terms of time, labor, and money. In addition, like all activities requiring human intervention, testing in this manner can often be error-prone and inconsistently executed.
Microsoft Visual Studio 2010 Premium and Ultimate contains the Code UI Testing tool that provides a way to automate these tests, so that regression testing can be performed more quickly, efficiently, and consistently.

A Coded UI Test gives developers and testers the ability to create tests that simulate user interactions with an application.
Coded UI Tests are stored in a Test Project. To create a new Test Project in Visual Studio,

  1. Select File | New | Project… The New Project dialog displays. 
  2. In the Installed Templates panel, expand the Visual C# or Visual Basic node and select the Test category.
  3. In the Project Type panel in the middle of the New Project dialog, select Test Project.
  4. Enter a name and location of the Test Project.
  5. Click the OK button. Visual Studio creates a new Test Project. You can view it in the Solution Explorer.

In our example, the project is named TestProject1. Link: Download TestProject1.

By default, a new Test Project contains a Unit Test class named UnitTest.cs. We won’t need this class, so it is safe to delete it.

Add a Coded UI Test to the project. (Project | Add Coded UI Test…) and provide a meaningful name for the map class.

The Generate Code for Coded UI Tests dialog displays. Select the Record actions, edit UI map or add assertions radio button. Click the OK button.

The Coded UI Test Builder toolbar displays in the bottom right of your screen.

Click the record button () to begin recording your actions. From this point, you can launch an application, navigate to a web site, click buttons, or enter data into forms – pretty much anything you do with your mouse and keyboard will be captured and turned into code by the recorder.

You can stop the recording either by clicking either the Pause button () or the Generate Code button ().
When the recording is paused, you can add an assertion by holding down the left mouse button over the Add Assertion button () and dragging the cursor to a control that contains a property against which you will create an assertion. A blue outline appears around any control as the cursor moves over it. Release the mouse while over the control to create an assertion about that control. An assertion declares an expected property value of the control. Comparing the actual property value against the expected value.

Clicking the Generate Code button generates C# code that reproduces the mouse and keyboard actions that you performed while the recorder was running.

The Generate Code button creates or updates three files in your project. The You can generate code button and create assertions as often as you  like. When you close the Coded UI Test Builder, Visual Studio generates three files share a similar name but different extensions: *.uitest, *.cs, and *.Designer.cs.  In our TestProject1 demo, the files are named files UIMap.uitest, UIMap.cs, and UIMap.Designer.cs. Because these files are related, UIMap.cs, and UIMap.Designer.cs appear beneath UIMap.uitest within the project hierarchy.
UIMap.uitest contains an XML file with information about the recorded steps.  If you don’t have the graphical interface to edit this file, you may want to download the Visual Studio 2010 Feature Pack 2 (http://msdn.microsoft.com/en-US/vstudio/ff655021.aspx ). This XML file is used to generate C# code stored in the UIMap.Deigner.cs  file.
Using the Coded UI Coded UI Test Editor, you can view each recorded step, change properties of a step; and split a method into multiple methods.

UIMap.Deigner.cs is overwritten every time any new recordings are created, so you should not edit this file.  Instead, move the method you wish to modify into the UIMap.cs file. This file is not overwritten, so your code can store anything you want here. UIMap.cs and UIMap.designer.cs are partial classes of the same class, so it doesn’t matter to the compiler in which file a method, property, or field is located.

Tuesday, July 24, 2012 3:37:00 PM (GMT Daylight Time, UTC+01:00)
# Wednesday, June 27, 2012

If you are new to performance and load testing, you need two things: knowledge of testing practices and knowledge of testing tools. .NET Performance Testing and Optimization: The Complete Guide by Paul Glavich and Chris Farrell provides both of these.

.NET Performance Testing and Optimization provides a solid overview of good testing practices, as well as practical information on how to use various commercial testing tools that are currently available.

The first three chapters cover principles of testing, such as which metrics you can measure, what information each metric provides, and when to care about each metric.

Glavich and Farrell describe the different types of tests and the goals of each. Performance Testing, for example, measures the speed at which an application responds to user input and events. Load Testing measures the number of concurrent users an application can reasonably support. Although they are often confused, the goals are different and the important metrics for each are different.

The rest of the book describes in detail various types of tests you can perform. Glavich and Farrell even provide step-by-step instructions to perform these tests with popular commercial products.

For those new to performance testing, for those needing a refresher on performance testing, or for those who want to know how to use commercial products to perform performance testing, .NET Performance Testing and Optimization  is a good source of information.

Wednesday, June 27, 2012 3:47:00 PM (GMT Daylight Time, UTC+01:00)
# Thursday, May 24, 2012

Here is Phil Japikse’s presentation on Testing Code From The Pit of Despair at the March 2012 Great Lakes Area .NET User Group (GANG).

Thursday, May 24, 2012 5:06:00 PM (GMT Daylight Time, UTC+01:00)
# Monday, April 25, 2011
Monday, April 25, 2011 3:45:00 PM (GMT Daylight Time, UTC+01:00)
# Monday, April 18, 2011
Monday, April 18, 2011 2:45:00 PM (GMT Daylight Time, UTC+01:00)
# Wednesday, September 22, 2010

This is a 2-part recording of Jim Holmes's presentation An Introduction To Unit Testing, delivered at the September 15 meeting of the Great Lakes Area .Net User Group.

Part 1
Part 2
Wednesday, September 22, 2010 12:21:39 PM (GMT Daylight Time, UTC+01:00)
# Monday, July 19, 2010
Monday, July 19, 2010 1:46:06 PM (GMT Daylight Time, UTC+01:00)
# Tuesday, March 23, 2010

Episode 78

In this interview, Jim Holmes discusses the importance of unit testing in writing high-quality, maintainable code.

Tuesday, March 23, 2010 4:25:14 AM (GMT Standard Time, UTC+00:00)
# Tuesday, February 9, 2010

Unit testing the critical methods of your application is important.

Generally, I focus on testing public methods because this is the interface that others use to interact with my library. Testing only public methods also safeguards me from modifying unit tests every time I refactor or optimize the encapsulated code of my libraries.

Unfortunately, sometimes critical methods are marked Private. Because I always create my unit tests in a separate project, this presents a problem: Private methods are only accessible to other methods in the same class; You cannot call a Private method from an external assembly.

You have several options when testing Private methods from a separate project.

  • Change the method's accessor to Public
  • Create a public 'accessor' to the method
  • Use reflection to access the method
  • Test a public method that calls this method.
  • Change the method's accessor to Internal and make Internal methods visible to your test project.

Each of these approaches has its shortcomings

Change the method's accessor to Public

This is probably too extreme as it breaks any abstraction you were trying to create. Too many public methods can clutter an API, making it overly complex.

Create a public 'accessor' to the method

This involves creating a public class and method decorated with the [Shadowing] attribute. It definitely adds a level of complexity to your class. When you ask MSTest to create a new Unit Test of a private method, you will be prompted to create an accessor.

Test a public method that calls this method

This is a popular choice. The idea is that public methods call private methods, so testing your public methods will call and test your private methods. To get good code coverage, you will need to know which methods are called (an approach known as "White Box testing".) Some people don't like to call this a unit test because multiple methods are called.

Use reflection to access the method

This is the most complicated of the methods listed here; But, if you don't have the source code and you feel you must test a private method, this is your only option.

Change the method's accessor to Internal and make Internal methods visible to your test project.

This method is a good compromise. By default, Internal methods are available only to other methods in the same assembly. However, you can an external project explicit permission to access Internal methods by adding the following line to AssemblyInfo.cs class of the file containing the method you want to test.

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("TestProject")]

where TestProject is the name of the project containing your unit tests.

When I have access to the source code, marking Internal methods visible is my preferred method of testing private methods. When I don't have access to source code, I tend only to test public methods.

Tuesday, February 9, 2010 3:54:29 PM (GMT Standard Time, UTC+00:00)