Testing C# Code in Production with Scientist.NET

Even if we have unit tests in place, problems can still occur when the code is released to production. This course will show you how to use Scientist.NET to test the new code in production to gain greater confidence before starting to use it.
Course info
Rating
(23)
Level
Intermediate
Updated
Sep 30, 2016
Duration
1h 30m
Table of contents
Description
Course info
Rating
(23)
Level
Intermediate
Updated
Sep 30, 2016
Duration
1h 30m
Description

Errors in production code can be costly to fix, more stressful for the development team, and frustrating for the end-user. In this course, Testing C# Code in Production with Scientist.NET, you will get to see how Scientist.NET allows sections of the application to be changed more safely by running both the existing code alongside the new code in production. You'll begin with an introduction to Scientist.NET before installing it and writing your first experiment. Next, you'll learn how to customize the configuration of experiments. Finally, you'll learn how to publish experiment data to SQL Server and analyze experiment results. After completing this course, you'll be ready to start testing new code in production using Scientist.NET before starting to use it.

About the author
About the author

With over 15 years experience, Jason Roberts is a Microsoft .NET MVP, freelance developer, and author.

More from the author
Working with Files and Streams in C#
Intermediate
3h 13m
Oct 12, 2018
Error Handling in C# with Exceptions
Intermediate
1h 37m
Aug 6, 2018
More courses by Jason Roberts
Section Introduction Transcripts
Section Introduction Transcripts

Course Overview
Hi everyone, my name's Jason Roberts. Welcome to my course, Testing C# Code in Production with Scientist. NET. I'm a Microsoft. NET MVP, freelance developer, and author. In this course, we're going to learn how Scientist. NET can give us greater confidence when releasing new code to the production environment. Some of the major topics that we'll cover in this course include the fundamentals of how Scientist. NET works, the additional benefits it gives us over and above unit testing, how to install and start using it, and also how to create and publish custom reports. By the end of this course, you'll understand the benefits that Scientist. NET offers, and how to use it to gain greater confidence that the code you're going to release to production will actually work in the live production environment. Before beginning the course, you should be familiar writing basic C# code in Visual Studio. I hope you'll join me on this journey with the Testing C# Code in Production with Scientist. NET course at Pluralsight.

Introduction to Scientist.NET
Hi, I'm Jason Roberts from Pluralsight. Welcome to this course, Testing C# Code in Production with Scientist. NET. In the world of carpentry there's a phrase, measure twice, cut once. And what this essentially means is, before chopping a piece of wood in half, we should measure it the first time, and the double-check our measurement before actually committing to sawing the piece of wood in half. This gives the carpenter greater confidence in what they're doing, and avoids costly mistakes. So in a typical, simplified workflow here we start off writing our code on our local computer, and maybe doing some testing. And once we're happy with the code on our local machine, we'll go and check it in to some kind of source control, and execute some tests in the development environment. In production here, we have the existing code. Once we're happy with the state of the code in the development environment, we'll go and replace the existing code in production with the new version of our code. But even though we followed a good approach in development and we've written or unit tests, and maybe some automated UI tests, once we deploy this to production, it actually fails and causes errors. So, in this approach we can say we're only measuring once before actually performing the cut. Essentially, Scientist. NET allows us to measure twice, and check the new code in the production environment before actually activating it. This gives us greater confidence that we're not going to break anything.