Okay, so welcome back. So in the first demonstration we got up and running with test-driven development and we created our initial unit tests and then we did the implementation and we followed the red-green refactor approach. So in this demonstration, I'm going to show you how to tidy up the current set of unit tests, condense them and use some different parts of what Xunit can provide.

So let's get started. So the first thing I want to show you is when we finished our first set of unit tests, we ended up with these three here, which unit tests the convert Bitcoins method, passing in different values for each of the unit tests. Now what we can do is, instead of having individual unit tests that we run on the same method, we can actually use a new attribute called, the theory attribute, which again is provided by the Xunit, unit testing framework.

Now theory works with the inline data attribute, also provided by Xunit. So we create a new attribute called inline data and in this we can pass in parameters. So in this case, we're going to have the currency, the number of Bitcoins and the expected output. And we can have multiples of these. So we can have one for USD and then we can have, say for two Bitcoins, we expect 200 to be returned. And we can keep building this up for the other currencies as well.

So we can do Great British pounds. In this case, one Bitcoin currently returns 200, therefore two will return 400. And then also for euros. So one Euro currently returns 300, therefore two euros will return 600. So we need to update the name of the unit test, 'cause we're not just passing in one Bitcoin and converting it into USD currency. So we need to generalize this part. So we're instead going to name this part of the unit test, BitcoinsToCurrency and it returns currency. And then we need to update the imports into this unit test.

So the first one will be string. It will be currency.. Second one will be int and it will be coins. And the third one will be int and it will be what we expect to be the converted dollar amount. Okay. So the way we read this is that the first parameter here is our currency, the second one is the number of Bitcoins and the third one is the expected returned value.

So we need to update the implementation within the unit test. So this will be currency. This will be the number of coins we're passing in. And then the expected returned value is this guy here. So we'll save that. We now rerun our unit tests. And we can see that everything has run successfully. So we've got nine unit tests. So again, the way you read this, is that each one of these ends up being a unit test of its own right. So we've got one, two, three, four, five, six there and then we've got our previous three that is the GetExchangeRate method. So that's a nice way to tidy up our unit tests using the theory attribute.

Now, one final thing I wanna show in this demonstration is the concept of using dotnet watch to automatically rerun our unit tests any time, any of the source code of our implementation or our units test change. The way we do this, is I'll jump back into our instructions under step two.

We can copy this command here. I'll paste it. Now again, what this is doing is that this is going to rerun our unit tests automatically any time any of the source code within our solution actually changes. Let's confirm that. Let's just put a example comment here. Now you save that file and as we can see down here, our unit tests are being automatically rerun for us. So that takes one part of the test driven development, red-green recycle workflow away from us. So we can just concentrate on writing our code, saving our files and watching the output as our tests get automatically rerun.

Okay, that completes this demonstration. Go ahead and close it and I'll see you in the next one.