Home » Posts tagged "unit test"

Unit Testing an Angular 2 CLI Project

This week we want to continue our series about Angular 2 by looking at the Unit Testing capabilities that Angular 2 provides for us.  What we want to cover today is:

  • Tweaking Karma to avoid using the Browser Window
  • Code Coverage
  • Tips to testing components

This article was written using Angular CLI version 1.0.0-beta.20-4  (Tip, if you are upgrading on windows, rm –rf node_modules dist temp just means to delete the three directories.  You can do that part manually, or install bash for Windows and run the command in bash.)

Unit Testing an Angular 2 CLI Project
Photo credit: jimmiehomeschoolmom via VisualHunt.com / CC BY-NC-SA

Continue reading “Unit Testing an Angular 2 CLI Project”

Exposing Secret JavaScript privates to Unit Tests

The question comes up all the time, “How do I access JavaScript privates from my Unit Tests?”  And invariably, the purist chimes in with the answer, “you don’t”.

But, isn’t the point of unit testing to allow us to test UNITs?  Why artificially limit our ability to test units if we don’t need to?  If we had the ability to create protected members, wouldn’t we tests those separately?

So, what follows is how I surface my private JavaScript members so I can access them during tests without having to make them public during the run of my protection code.

Exposing Secret JavaScript privates to Unit Tests

Continue reading “Exposing Secret JavaScript privates to Unit Tests”

ES2015 Code Coverage and Jest (React JS Unit Testing)

As I’ve mentioned before, I’m in the middle of putting together a React reference app and I’m doing it using Test Driven Development.  The problem is, the standard tools for implementing ES2015 code coverage with Jest make it hard to see at a glance if you have 100% code coverage or not because of some issues with the way Jest tells Babel to do the transformations by default, the way Babel transforms the code and implements the auxiliaryCommentBefore option and the way that Istanbul parses the ignore next comments.

I’ve been working on solving this problem for the last month and a half off and on.  I’ve even posted a question about this on Stack Overflow, so I’m pretty sure no one else has a solution for this yet.  I’m not going to say my solution is the best way to solve this problem, but it is a solution, which is better than what we have so far.

ES2015 Code Coverage and Jest

Continue reading “ES2015 Code Coverage and Jest (React JS Unit Testing)”

100% Code Coverage Possible?

100% code coverage

In response to my post “Excuses For Not TestingKris K asked:

There is also another side of Unit Tests. Some companies are so fixated they aspire to have 100% Unit Tests coverage and they make programmers write Unit Tests for legacy code for no reason. Just for the sake of having Unit Tests. … [I] wonder if you had any similar experiences and what you think about this approach. I guess the 100% extreme is better than no tests at all, but it can make the developers very bored and feeling useless.

And my initial reaction to this was, “WOW!  So much to respond to here.  I think this is worth a blog post. Continue reading “100% Code Coverage Possible?”

NUnit Test Code Structure

UnitTestStructure

There are two basic ways to structure the code you will be working on to Unit test the code in your main application using NUnit.  Arrange/Act/Assert (AAA) is what I refer to as the “Classic” method.  It has been around for as long as I’ve known about unit testing. The second method is the Given/When/Then (GWT) structure.

While both methods get the job done and both methods essentially help you structure your test, I think that the Given/When/Then structure helps us think about what we are trying to test from a more functional perspective.  Arrange/Act/Assert is more of a code based approach.

Since, in the end, what we care about is the functionality that we have coded.  I prefer Given/When/Then.  I also think GWT is better suited to Test Driven Development since in Test Driven Development, we are already in the mindset of “What is it that I’m trying to accomplish?”  And not, “What did I do and how do I test it?”

Arrange/Act/Assert

The classic method of arranging our NUnit test code conforms to the “Arrange/Act/Assert” pattern.  Using this pattern, we setup our code so that it is in the state we need it to be to perform the test.  Then we perform some distinct action on the code.  This action should exercise one and only one feature.  And then, finally we assert that the action we performed resulted in some expectation being fulfilled.

What?  Huh?

So, maybe some code will help.

Let’s assume that we have a class, Calculator, that has a method, Add:

public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

To test this class, we create another class in our test project that we will name CalculatorTest.  Well, what do we want to test in our Calculator class?  We want to test that when we add two numbers together, the proper sum comes back.  So, we’ll need a test method.  It is customary to name our methods what we are trying to test for, so we will call our test method AddShouldReturnSumOfTwoNumbers().

Following the Arrange/Act/Assert pattern, the first part of our method will create the Calculator object, then we will call the Add method, passing it two numbers, and then we will Assert that the proper result was returned.

[TestFixture]
public class CalculatorTest
{
    [Test]
    public void AddShouldReturnSumOfTwoNumbers()
    {
        // Arrange
        var sut = new Calculator();

        // Act
        var returnValue = sut.Add(3, 7);

        // Assert
        Assert.That(returnValue, Is.EqualTo(10));
    }
}

Given/When/Then

An alternate way of thinking about test is by using the Given/When/Then construct.  It essentially arranges the code in the same way, but I think it helps you think about what it is you are trying to test better.  Arrange/Act/Assert (aka AAA) tends to have you think about your code from a programmer’s perspective.  “This is what my code does.”  The Give/When/Then method thinks about the problem more from a requirements perspective.  At the end of the day what is important is that you have test around your code, so I’m not going to spend a lot of time arguing that one way is particularly better than the other.  But GWT is what I use. Since this is my post, that’s what we are going to use for the remainder of this book.

So going back to our Calculator example, what would GWT look like?

[TestFixture]
public class CalculatorTest
{
    [Test]
    public void AddShouldReturnSumOfTwoNumbers()
    {
        // Given that we have a calculator
        var sut = new Calculator();

        // When I add 3 and 7 together
        var returnValue = sut.Add(3, 7);

        // Then the result should be 10
        Assert.That(returnValue, Is.EqualTo(10));
    }
}

See, it’s all the same stuff, so whatever helps you think about what you are testing is what you should use.