Good point on checking for Discounts.Count > 0 and changing that to return 0 instead.

As far as setting the methods to protected for the reason of unit testing, I’m not sure I agree with this. A unit test for this class would excercise the public method CalculateGrandTotal with specific inputs. Granted, Discounts would have to be initialized via a ctor or something along those lines to get different Discounts in there. I digress however, my point is you should not be testing those individual methods, but instead should be treating the public method as a black box. I don’t care how the class accomplishes it’s work, just as long as all code paths are executed for proper coverage.

Testing private methods is a code smell IMO. The whole reason for having them private is because the class knows how to accomplish it’s work. You would simply have several different scenarios for testing CalculateGrandTotal to excercise all paths.

private decimal CalculateDiscounts(decimal subTotal)
{
if (Discounts.Count > 0)
{
foreach (decimal discount in Discounts)
subTotal -= discount;
}
}

But i can see potential danger if Discounts is null. So better write it this way:

private decimal CalculateDiscounts(decimal subTotal)
{
if (Discounts.Count == null)
return 0;

foreach (decimal discount in Discounts)
subTotal -= discount;
}

Also make these methods at least as protected because one may also want to unit test them.

subTotal -= CalculateDiscounts(subTotal);
subTotal += CalculateTax(subTotal);

or to have called them CalculateAndDeductDiscounts() and CalculateAndAddTax() if they are doing the addition and deduction too.