Oregon Institute of Technology
Lab 2
Due: Demonstrate in Lab April 9 th.
Unit Testing
Throughout the course we will create, manage and run various types of tests. In this lab you will look at the first of those testing types - Unit Tests. You will use the unit testing framework within Visual
Studio, first by creating a unit test and then creating the code to be tested (test driven development,
TDD).
In addition to standard unit tests, you also will write a data driven test. These are tests where a given method has to be executed many times with different test data. Rather than have multiple tests within a single test case or multiple similar test cases per test class, you can provide one test case and supply the data for the test in an excel spreadsheet (or database).
Unit Tests alone do not provide enough information, so you will also run code coverage.
Steps :
In this lab we also will adhere to the paired programming paradigm. So, you will need to pick a partner. You and your partner will need to choose one of your team projects to work from. If you were not in the Patterns class (or haven’t coded in C#) choose a partner that was in the Patterns class. Add a new folder to your source control repository—call it whatever you want—“Stack” would be a good name. Then set up a new workspace mapping for your new folder. Note: The Unit Testing Framework does not work on the Z drive so your workspace mapping will need to map to your local machine.
Before starting to code: Add a Feature work-item, assign it to either you or your partner, and give it the title “Stack Feature.” Link three child work-items to your Feature work-item. The first two should be
Task work-items and the last one should be a Test work-item. Give them the titles “Implement Stack
Interface”, “Add Mystack Test Project”, and “Implement Test Stack Methods” respectively.
Write a custom work-item query that will show the work-items assigned to you in a tree format.
Next, add two source control check-in policies. One that requires comments for each check-in, and the other that requires task association with each check-in. As you work through the lab, change the states of the tasks to reflect your current status and associate your check-ins with the relevant task work-item.
Throughout the lab, check-in your code and update the associated work-item states at logical intervals.
For this lab, you will create unit tests for a stack class packaged in a C# class library. Create a new C# class library and name the solution “StackLab.” Be sure to save the solution in the correct location on your hard drive relative to your new workspace mapping. Change the name of the class1.cs file to
IMyStack.cs and change the “class” keyword to “public interface”. You are going to implement a stack collection type. A stack is a Last-In-First-Out collection. Users of the stack 'push' data items onto the

stack and 'pop' them off when they are finished with them. Your stack also will have the capability to remove all data items from the stack and look at the topmost entry on the stack. For simplicity, we will work with a stack of integers.
Your IMyStack interface will have five methods:
Push—pushes an integer on the top of the stack
Pop—pops the top integer value off the stack and returns the integer value
Top—returns the integer value on the top of the stack without removing it
Size—returns the size of the stack
Clear—empties the stack
Add a MyStack class that inherits from IMyStack and stub out the methods. Use a c# array data type for your stack: int[] numbers = new int[10];
Add a test project to your StackLab solution. Add a reference to the StackLab dll and the namespace to the test project. Add a reference to System.Data to your test project (for the TestContext property).
Now write test methods for the code to be tested and then make the tests go green by writing the code to be tested. For example, create a test method for the MyStack’s Push() method, then write the code for the MyStack’s Push() method. Implement the following test methods:
TestPushSucceeds
TestPopSucceeds
TestTopSucceeds
TestSizeIsCorrect
TestClearSucceeds
TestOverFlow—pushing onto a full stack
TestUnderFlow—popping off an empty stack
If your stack methods need to throw an exception (for example when trying to push when the stack is full), throw one of type “InvalidOperationException.” throw new InvalidOperationException( "Can’t push onto a full stack" );
After all of your tests pass, run code coverage to validate that your tests are thorough. Configure the solution to exclude code coverage on the testing dll by adding the [ExcludeFromCodeCoverage] attribute to the test class and add the System.Diagnostics.CodeAnalysis namespace to the TestProject.
Data Driven Test:
For the following steps use the Calc solution posted on the sharepoint site as a guide.
Create a spreadsheet, call it TestData.xlsx and save it in the directory where the .csproj file of the test project is located.


Add the spreadsheet to the VS test project. Right click on the spreadsheet and select properties.
Set the “Copy to Directory” property to “Copy Always” and the “Build” property to “Content.”

Change the name of Sheet1 to StackData—right click on the sheetname (at the bottom of the spreadsheet) and select Rename.

In the spreadsheet, create three columns called, pushNumber, popNumber and expectedLeft.
You do this by typing these values into the first three cells (A1, B1 and C1).

Give each of these columns values that can be used to test the Stack implementation. That is, to push a given number of items onto the stack, pop some items off and check that the correct number of items remains on the stack

Add descriptive comments to each test in the spreadsheet.
Now, lets add a data driven test method called TestPushPop(). In this method you will use the data from the excel spreadsheet to push a given number of items onto the stack, pop some items off and check that the correct number of items remains on the stack. Add the DeploymentItem and DataSource attributes to your data driven test method (see .txt file on SharePoint site).

Add the public TestContext property to your test class and add a reference to System.Data

Inside the test method define three variables: int pushNumber, int popNumber and int expectedLeft. These will be initialized from the spreadsheet to the number of items to push onto the stack, the number of items to pop off the stack, and the expected number left on the stack

Add the code to read the data from the excel spreadsheet and assert on the results
Run the test to see if it executes as expected—debug any unexpected results.
Once all code works as expected, check the solution into source control and update your associated work-item states. Additionally, label your code to mark the end of “LastNameStackSprint1.”
Note: If we had the TFS power tools installed, we could add a check-in policy that forces all unit tests to run and pass before code can be checked in.
Lab Check Off List:
1.
Run all tests with code coverage. All tests should pass. Appropriate tests should check for expected exceptions.
2.
Run custom tree query to see all work-items and the parent-child relationships. Also, work-items should show history of check-ins
3.
Add a comment somewhere in the code and demonstrate check-in policies during check-in.
4.
Get previous version using label—check to see the comment added in step 3 is no longer in the code.