{"id":231577,"date":"2021-01-13T13:18:36","date_gmt":"2021-01-13T21:18:36","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/visualstudio\/?p=231577"},"modified":"2021-01-13T13:45:05","modified_gmt":"2021-01-13T21:45:05","slug":"visual-studio-for-mac-helps-you-write-tests","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/visualstudio\/visual-studio-for-mac-helps-you-write-tests\/","title":{"rendered":"[Guest Post] Visual Studio for Mac Helps You Write Tests"},"content":{"rendered":"

You\u2019re writing tests for your code, right? No? Just say \u2018yes\u2019. It\u2019ll make this blog post go a lot easier. So anyway, I\u2019m happy to hear that you\u2019re writing tests for all your code. Whether you\u2019re following the \u201ctest first\u201d \/ Test-Driven Development (TDD) approach or whether you\u2019re just writing some unit tests or integration tests, Visual Studio for Mac has some nice features to make your life as a developer a lot easier.<\/p>\n

In this article, I\u2019ll walk you through the process of writing and running unit tests using Visual Studio for Mac.<\/p>\n

Some Terms<\/h2>\n

Before I jump in on the features, let\u2019s get a few terms out of the way. (For more information on the different types of tests and why you might choose one over the other, check out this article<\/a>.)<\/p>\n

What\u2019s a \u201cunit test\u201d? A unit test is a piece of code that exercises and verifies the execution of a piece of code in your application. That application is referred to as the \u201csystem under test\u201d or SUT. Let\u2019s say I\u2019m writing a .NET Core application using C#. When I\u2019m writing code, if I have a C# class in my application, I\u2019ll have at least one test class in my test project. For every public method in my application\u2019s class, I\u2019ll have at least one test method in my test class that tests the corresponding application method.<\/p>\n

If you\u2019re new to automated testing, you might want to check out this article on unit testing best practices<\/a>.<\/p>\n

Test-driven development (TDD) isn\u2019t a type of test \u2013 it\u2019s a way of writing features & tests. TDD is commonly referred to as \u201ctest first\u201d and the idea is that you\u2019re going to write your tests before you write your application code. Starting with your tests gets you a better overall design and cleaner code.<\/p>\n

Writing your tests first can be a little cumbersome because you\u2019re starting with almost nothing. Thankfully, Visual Studio for Mac has some features that help to make it easier. In this example, I\u2019ll show how we can generate code as part of our test-first development workflow.<\/p>\n

Tour of the Sample Code<\/h2>\n

Source code is available at https:\/\/github.com\/benday-inc\/visual-studio-mac-tdd-demo<\/a>. This repo contains both \u201cbefore\u201d code so that you can code along and also an \u201cafter\u201d folder that has the completed sample. If you\u2019re interested in starting from scratch, you might want to check out this guide to getting started with the Testing tools in Visual Studio for Mac<\/a>.<\/p>\n

Let\u2019s say that you\u2019re going to write a calculator using test-driven development (TDD). The first step is to start writing your tests. To save time, I\u2019ve created a .NET Core solution in Visual Studio for Mac that consists of an MSTest<\/a>-based unit project, an class library for my application, and an ASP.NET Core MVC web application.<\/p>\n

\"Visual
Figure 1 – The empty calculator solution in Solution Explorer<\/figcaption><\/figure><\/p>\n

The class that contains the calculator logic is eventually going to go into the Benday.CalculatorDemo.Api<\/code> class library project but at the moment that class doesn\u2019t exist. We\u2019re going to start writing our test code in a class called CalculatorFixture<\/code> in the Benday.CalculatorDemo.UnitTests<\/code> project.<\/p>\n

Rename the Unit Test Class<\/h2>\n

Let\u2019s start by editing UnitTest1.cs. Right now that class just has the default structure for an MSTest-based unit test in it and the class is named UnitTest1<\/code>.<\/p>\n

\"New
Figure 2 – The empty calculator fixture test class<\/figcaption><\/figure><\/p>\n

Let\u2019s change the class name to be CalculatorFixture<\/code>.<\/p>\n

\"Unit
Figure 3 – Rename class to be CalculatorFixture<\/figcaption><\/figure><\/p>\n

Right now the file name doesn\u2019t match the class name \u2013 the file is named UnitTest1.cs<\/code> and the class name is CalculatorFixture<\/code>. There\u2019s an easy way to fix that. Click on the \u201cCalculatorFixture<\/code>\u201d word of the class declaration and press Option-Enter to bring up the Quick Actions and Refactorings<\/a> menu. One of the options is Rename type to CalculatorFixture<\/strong>. Visual Studio for Mac is smart enough to know that your class name doesn\u2019t match the class name implied by your filename so if you choose this item from the menu, it\u2019ll rename the class for you.<\/p>\n

\"Visual
Figure 4 – Use the Quick Actions and Refactorings menu to rename the file to CalculatorFixture.cs<\/figcaption><\/figure><\/p>\n

Now if you look at the Solution Explorer window, you\u2019ll see that the filename now says CalculatorFixture.cs<\/code>. Sure, this isn\u2019t life-changing but it\u2019s one of those little things that makes coding a little more pleasant.<\/p>\n

\"Solution
Figure 5 – Renamed file in solution explorer<\/figcaption><\/figure><\/p>\n

TDD Step #1: Write Your Tests<\/h2>\n

Now let\u2019s write the empty structure of our calculator tests by adding test methods for Add()<\/code>, Subtract()<\/code>, Multiply()<\/code>, and Divide()<\/code>. When I know that I\u2019m going to want to write a test case but I\u2019m not quite ready to write it, I\u2019ll put in a call to Assert.Inconclusive()<\/code>. If I left the test method code empty, it would look like a passing test but if I put the call in to Assert.Inconclusive()<\/code>, it\u2019ll provide me a nice placeholder reminding me that I need to come back to implement the tests. It\u2019s not going to fail but it won\u2019t pass either.<\/p>\n

\"Unit
Figure 6 – Test methods for Add, Subtract, Multiply, and Divide marked as Inconclusive<\/figcaption><\/figure><\/p>\n

Run the Tests<\/h3>\n

Now that we\u2019ve got some code, let\u2019s try to run the tests. The easiest way to run all the tests in a test class is to right-click on the class name and choose Run Test(s)<\/strong>.<\/p>\n

\"CalculatorFixture
Figure 7 – Run Tests in a Test Class<\/figcaption><\/figure><\/p>\n

You should see the Tests panel appear and your tests should run.<\/p>\n

\"Tests
Figure 8 – The tests ran and were inconclusive<\/figcaption><\/figure><\/p>\n

Write the Test Code<\/h3>\n

Now let\u2019s write some test code for the Add()<\/code> method.<\/p>\n

\"Additional
Figure 9 – Code for the Add() test method<\/figcaption><\/figure><\/p>\n

If you press Command-B to build your solution, this is going to fail. The error should be something like \u201cCalculatorFixture.cs(39,39): Error CS0246: The type or namespace name ‘Calculator’ could not be found\u201d. This is because there\u2019s no class named Calculator yet.<\/p>\n

In the API project, there\u2019s a class called Class1.cs<\/code>. Let\u2019s rename this class to Calculator and change the filename to Calculator.cs<\/code>.<\/p>\n

After you\u2019ve renamed that class to be Calculator, you\u2019ll still be getting an error because of a missing using statement. In CalculatorFixture.cs<\/code>, on line 12, click on the word Calculator and then type Option-Enter to bring up the Quick Actions and Refactorings menu.<\/p>\n

You should see an option to add a using statement. Choose that option.<\/p>\n

\"Context
Figure 10 – Add the missing using statement<\/figcaption><\/figure><\/p>\n

Now that that\u2019s fixed, try to rebuild the solution. You should now be getting an error that says \u201cError CS1061: ‘Calculator’ does not contain a definition for ‘Add’ and no accessible extension method ‘Add’ accepting a first argument of type ‘Calculator’ could be found\u201d. This is because there\u2019s no method named Add()<\/code> on the Calculator class.<\/p>\n

TDD Step #2: Create an implementation \/ Add the Missing Method<\/h2>\n

Alright. So we\u2019re trying to write that Add() method and our test class is failing to compile because that method doesn\u2019t exist yet. Let\u2019s use the Quick Actions and Refactorings menu to generate that method for us.<\/p>\n

In CalculatorFixture.cs, on line 19, click on the word Add() and then type Option-Enter to bring up the Quick Actions menu. One of the options should be \u201cGenerate method \u2018Calculator.Add\u2019\u201d. If you choose this option, Visual Studio for Mac will create a basic implementation for you including the arguments and return values.<\/p>\n

\"Context
Figure 11 – Generate the Add() method<\/figcaption><\/figure><\/p>\n

After you run the Generate method action, when you open up Calculator.cs<\/code>, you\u2019ll now see that there\u2019s an implementation of the Add()<\/code>\u00a0method that throws a NotImplementedException<\/code>.<\/p>\n

\"Generated
Figure 12 – Generated Add() method<\/figcaption><\/figure><\/p>\n

Now when you rebuild your solution, it builds successfully without errors. When you run all your tests, you should now see that the Add test is failing and that the other 3 tests are saying inconclusive.<\/p>\n

\"Test
Figure 13 – Add test is failing<\/figcaption><\/figure><\/p>\n

Implement the Add() Method<\/h3>\n

Next let\u2019s implement the add method in the Calculator class.<\/p>\n

\"Add
Figure 14 – Implement the Add() method<\/figcaption><\/figure><\/p>\n

After you\u2019ve added the implementation for the Add()<\/code> method, re-run the tests. The test for Add should pass.<\/p>\n

\"Test
Figure 15 – The test for Add() passes<\/figcaption><\/figure><\/p>\n

Summary<\/h2>\n

From here you can now implement the rest of the tests using the same process. Visual Studio for Mac\u2019s ability to generate code for you while you\u2019re writing your test-first unit tests can really help you to avoid some common coding headaches.<\/p>\n

If you\u2019re looking for more advanced info on automated testing techniques such as how to break up testing dependencies and testing ASP.NET application security, check out my Architecting an ASP.NET Core MVC Application for Unit Testability course on Pluralsight<\/a>.<\/p>\n

About the Author<\/h3>\n

Benjamin Day is a consultant and trainer specializing in software best practices using Scrum with Microsoft\u2019s DevOps tools. Ben\u2019s main areas of emphasis include Azure DevOps, Scrum, software testing, and software architecture. He is a Microsoft MVP, a certified Scrum trainer via Scrum.org, and a speaker at conferences such as Pluralsight Live and VSLive. When not developing software, Ben\u2019s been known to go running and sea kayaking in order to balance out his love of cheese, cured meats, and champagne. His online courses are available at https:\/\/courses.benday.com<\/a> and at http:\/\/www.pluralsight.com<\/a>. He can be contacted via http:\/\/www.benday.com<\/a>.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

You\u2019re writing tests for your code, right? No? Just say \u2018yes\u2019. It\u2019ll make this blog post go a lot easier. So anyway, I\u2019m happy to hear that you\u2019re writing tests for all your code. Whether you\u2019re following the \u201ctest first\u201d \/ Test-Driven Development (TDD) approach or whether you\u2019re just writing some unit tests or integration […]<\/p>\n","protected":false},"author":50156,"featured_media":231592,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[155],"tags":[1666,3743,452],"class_list":["post-231577","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-visual-studio","tag-testing","tag-visual-studio-2019-for-mac","tag-visual-studio-for-mac"],"acf":[],"blog_post_summary":"

You\u2019re writing tests for your code, right? No? Just say \u2018yes\u2019. It\u2019ll make this blog post go a lot easier. So anyway, I\u2019m happy to hear that you\u2019re writing tests for all your code. Whether you\u2019re following the \u201ctest first\u201d \/ Test-Driven Development (TDD) approach or whether you\u2019re just writing some unit tests or integration […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts\/231577","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/users\/50156"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/comments?post=231577"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts\/231577\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/media\/231592"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/media?parent=231577"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/categories?post=231577"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/tags?post=231577"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}