Book Image

Improving your C# Skills

By : Ovais Mehboob Ahmed Khan, John Callaway, Clayton Hunt, Rod Stephens
Book Image

Improving your C# Skills

By: Ovais Mehboob Ahmed Khan, John Callaway, Clayton Hunt, Rod Stephens

Overview of this book

This Learning Path shows you how to create high performing applications and solve programming challenges using a wide range of C# features. You’ll begin by learning how to identify the bottlenecks in writing programs, highlight common performance pitfalls, and apply strategies to detect and resolve these issues early. You'll also study the importance of micro-services architecture for building fast applications and implementing resiliency and security in .NET Core. Then, you'll study the importance of defining and testing boundaries, abstracting away third-party code, and working with different types of test double, such as spies, mocks, and fakes. In addition to describing programming trade-offs, this Learning Path will also help you build a useful toolkit of techniques, including value caching, statistical analysis, and geometric algorithms. This Learning Path includes content from the following Packt products: • C# 7 and .NET Core 2.0 High Performance by Ovais Mehboob Ahmed Khan • Practical Test-Driven Development using C# 7 by John Callaway, Clayton Hunt • The Modern C# Challenge by Rod Stephens
Table of Contents (26 chapters)
Title Page
Copyright and Credits
About Packt
Contributors
Preface
8
What to Know Before Getting Started
17
Files and Directories
18
Advanced C# and .NET Features
Index

Different types of test


Over the course of the next few chapters, we will be leaning towards a particular style of testing, but it is important to understand the terminology that others will use so that you can relate when they speak about a certain type of test. 

Unit tests 

Let's jump right in with the most misused and least understood test type. In Kent Beck's book, Test-Driven Development by Example, he defines a unit test as simply a test that runs in isolation from the other tests. All that means is that for a test to be a unit test, all that has to happen is that the test must not be affected by the side-effects of the other tests. Some common misconceptions are that a unit test must not hit the database, or that it must not use code outside the method or function being tested. These simply aren't true. We tend to draw the line in our testing at third-party interactions. Any time that your tests will be accessing code that is outside the application you are writing, you should abstract...