Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
This chapter is about unit testing, which is a very developer-centric type of test. Let me start with my definition of a unit test. A unit test is an automated chunk of code that calls a class or a method and verifies that our assumptions about the behavior of the code under test are correct. Unit tests are commonly written using a unit testing framework. They should always be automated and easily accessible. Anyone on your team should be able to run the unit tests at anytime to verify that the code under test is working, and that no one has broken the build. Let's look at the unit testing tools inside Visual Studio.
I am going to be working with this project called WorkingWithUnitTests. First, let me show you the code I am going to test. It's inside this Book class Double-click on the Book class and you'll see that this class has one property called Title, one property with a getter and a setter, and a property called Price, and then I have two methods: UpdatePrizeByPercent and SaveBook. And here is a question for you: how do you know about the text in your code? My general feeling is that you only need to text code that contains logic statements.
So if your method has a loop construct, or an If statement, or it contains a calculation, it needs to be tested. Not all code qualifies, however. It's a waste of time to test simple property getters. So looking at this code up here, it doesn't make any sense to test this because there is no calculation going on. I will right my first unit test by going to the Test menu and choosing New Test. Within this dialog, I need to pick my testing language. I will choose C#, and then I will click on this Unit Test template. Most often, you can write your unit tests and the code at the same time.
There are many in the developer community that advocate writing your test first before writing any code. This is known as test-driven development. I agree with many of their principles, but for this movie, I'm adding tests to a prewritten code. I am going to call my unit test BookUnitTest, and then I am going to click OK. Visual Studio realizes I do not have a test project yet, so it prompts me for name for my new project. That looks like a great name for a unit testing project. I will click on Create and then on OK on this dialog. Several things happened in my project.
First of all, a new folder was added called Solution Items, with a few test items in there. Then a new UnitTest project was added, including this C# file down here, BookUnitTest. Let's see what's inside here. Double-click. Here is the class that is going to contain my testing code, and the way we tell the unit testing framework that this is a test class is by putting this TestClass attribute on the class itself. And then each method that I want to write that is going to test my code is going to be marked with this TestMethods.
That's so that the unit testing framework can find this method. Let me show you another way of adding a unit test. I will use a wizard this time. I'll click on this Unit Test Wizard, verify it is going to go in a UnitTest project, click OK and then over here, I am going to save my changes to my project. I'm going to select the class that I want to test. Test this book class, and I only need to test the SaveBook book and the UpdatePriceByPercent methods. So I will unselect everything else and then click OK.
This time, it wrote a slightly better test class. If you'll notice, my test methods now say SaveBook class, and there is a little bit of sample test code in here. Now I am going to delete these and put my own in here. I have already prewritten the code for these tests. They are in this Assets folder. I am going to first start by using this IncreasePrice.txt file. Double-click on this one and copy all of this code and then paste it in BookTest.cs.
I think I just double-clicked on the title. I detached this from the window. The way you put it back is you Ctrl+double-click on the header. I will paste my code in. Here is my TestMethod attribute, and the way I like to name my tests is by using the name of the method that I am going to test, the scenario that I am testing, and the expected behavior. It makes for a long name, but any developer that's looking at this test knows what it's expected to do. Now, what am I doing in my test case? I am instantiating an instance of that class, the Book class.
I am trying to verify that this UpdatePriceByPercent function works the way I want, which is I pass in a value, and it updates the price. So first, I am going to set a price for the book, then I am going to call my UpdatePriceByPercent, and then I am going to use one of the test classes, which is called Assert. I am going to use that to verify that the results are what I expect them to be. There are a number of Assert methods. If you look at the Assert class itself, you can see there are lots of test methods here: AreSame, there is a method called IsFalse, another one down here called IsNull, IsNotNull.
I have picked one called AreEqual, and the syntax for this is you pass in the expected value and then you pass in the actual value, and the Assert will verify whether these are correct or not. So what am I doing? I'm asserting that I should have 10 times 0.05, and then I'm saying, now look at the Book.cs and see if it has that value. Let's run the test. To run the test, I will go to the Test menu, choose this Windows submenu, and choose Test List Editor. I'll then build my project, which will build my test and my regular project, and it shows two test methods. The one that I just wrote down here is the UpdatePriceByPercent.
I will put a check mark here, and then I'll come up and run checked tests. At the bottom-half of the screen you'll see that there is a Passed result. It says Test run is complete. I had made one test. One test passed. You want to have all green lights down here. Now what happens if a developer comes along and goes to this book class and make a mistake. They look at this code and say, I am going to refactor this--maybe I should have been dividing. So they make this change, and they compile the application. I did a Ctrl+Shift+B to compile the application this time.
Then when you run the unit test the next time--I will go over here and do Refresh--and then when I run my unit test, that developer immediately sees that change they made 10 minutes ago is causing one of our unit tests to fail. So they are going to back and look at me and say, what did I do to break the build? Let's go back and fix that code because I want all green lights in a few minutes. Go back over here. Let me switch this back to multiple. And I have got two more text I want to add to BookTest, and what I am verifying this time is that the SaveBook method is working the way I expect.
So look what happens if I try to save the book. I look at the price that's currently stored in the Book class and if it's less then zero, then I throw an ArgumentOutOfRangeExeption. And if the price is larger than 90, I throw the same ArgumentOutOfRangeExeption. So when I write my test cases, I need to make sure that if you pass in a negative value, it throws that exception. So let's go to SaveBook1, and copy this code. I will go to my BookTest class and paste it, and then I might as well bring over the other bit of code while I am at it.
I will go over here and get the SaveBook2 and copy this code and paste it in BookTest. Then I will build the project, and then I will step through the code and show you what's it doing. In this first test, I am instantiating the book, I'm setting a negative price, and then I'm attempting to save the book. In the second test, I'm doing exactly the same thing, only I am setting an $80 price and saving the book.
Now, I expect this method to throw an exception, so I put this attribute up here to tell the testing harness, it's okay if it throws an exception. In fact, I expect it to throw exception, and this is the exception I expect: ArgumentOutOfRange. Now we will go test our code. Switch over to the test editor. You see there is two new unit tests listed here. I'll check both of those and then run my tests. And down at the bottom of the screen, you see that the UpdatePriceByPercent passed, the negative one passed because it threw that exception, but this one is not throwing any exception, and why not? Let's go and look at my test code. Because I didn't pass any number that was higher than 90.
So if I change this value to 90.01, rebuild my application, switch over to the Test editor and run my tests again, I get all green lights. This is what you're looking for. Every time you write code, you write a unit tests, you write the conditions that you want to test, and then you run your tests every time you make a change in your code. Make sure you haven't broken any of your pre-existing tests. Now there are other asserted conditions they should explore when you have time, and in the next movie, I'll show you another type of test called performance testing.
Get unlimited access to all courses for just $25/month.Become a member
61 Video lessons · 99304 Viewers
56 Video lessons · 112568 Viewers
71 Video lessons · 81388 Viewers
131 Video lessons · 39073 Viewers
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.