Comprehensive Test Coverage

[BelfDev]

Hello everyone,

I would like to propose that we follow TDD principles for the next lab exercises. In other words, prior to actually writing the proper methods, we first screen through the instructions and write unit tests (JUnit).

• Week 1 Unit Tests | @BelfDev
• Week 2 Unit Tests | @gsears
• Week 4 Unit Tests
• Week 5 Unit Tests

This way everyone can validate if their own solutions work properly. Does it sound good?
@Arden488 @gsears @Tumonn

[BelfDev]

Searching for naming conventions I found myself in a bit of a dilema.

Although BDD-inspired naming convention Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior is currently very popular, I think it suits user-centric applications better.

In this repo we are basically contributing with isolated exercises whose methods don't really depend on any previous state/preconditions. Therefore, I think the use of MethodName_StateUnderTest_ExpectedBehavior would be more straightforward.

Any thoughts? @Arden488 @gsears

[gsears]

Hey! Sounds like a great plan. I've got some unit tests for the prime number code, I'll ship them over as it was the first thing I actually did 'TDD' with on the course.

Haven't looked into naming conventions, but that certainly sounds good.

To get around the 'MethodName_' part, I actually used this library:

https://github.com/bechte/junit-hierarchicalcontextrunner/wiki

Allowed for creating subclasses within the class, which worked really well for separating method tests but still encapsulating it all in the same class. Here's an example from my code:

import static org.junit.Assert.assertTrue;
import static org.junit.Assert.assertFalse;

import org.junit.runner.RunWith;
import org.junit.Test;

import de.bechte.junit.runners.context.HierarchicalContextRunner;
@RunWith(HierarchicalContextRunner.class)
public class PrimePrinterTest {
    public class IsPrimeNumberTest {

        @Test
        public void zeroIsNotPrime() {
            assertFalse("0 is not a prime number", PrimePrinter.isPrimeNumber(0));
        }

        @Test
        public void oneIsNotPrime() {
            assertFalse("1 is not a prime number", PrimePrinter.isPrimeNumber(1));
        }

        @Test
        public void returnsTrueForPrimeNumbers() {
            final int[] PRIMES = {2, 3, 5, 7, 11, 13, 23};
            for (int x : PRIMES) {
                assertTrue(x + " is a prime number", PrimePrinter.isPrimeNumber(x));
            }

        }

        @Test
        public void returnsFalseForNonPrimes() {
            final int[] NON_PRIMES = {4, 6, 12, 21, 36};
            for (int x : NON_PRIMES) {
                assertFalse(x + " is not a prime number", PrimePrinter.isPrimeNumber(x));
            }

        }
    }
}

[BelfDev]

Hey! Sounds like a great plan. I've got some unit tests for the prime number code, I'll ship them over as it was the first thing I actually did 'TDD' with on the course.

Haven't looked into naming conventions, but that certainly sounds good.

To get around the 'MethodName_' part, I actually used this library:

https://github.com/bechte/junit-hierarchicalcontextrunner/wiki

Allowed for creating subclasses within the class, which worked really well for separating method tests but still encapsulating it all in the same class. Here's an example from my code:

import static org.junit.Assert.assertTrue;
import static org.junit.Assert.assertFalse;

import org.junit.runner.RunWith;
import org.junit.Test;

import de.bechte.junit.runners.context.HierarchicalContextRunner;
@RunWith(HierarchicalContextRunner.class)
public class PrimePrinterTest {
    public class IsPrimeNumberTest {

        @Test
        public void zeroIsNotPrime() {
            assertFalse("0 is not a prime number", PrimePrinter.isPrimeNumber(0));
        }

        @Test
        public void oneIsNotPrime() {
            assertFalse("1 is not a prime number", PrimePrinter.isPrimeNumber(1));
        }

        @Test
        public void returnsTrueForPrimeNumbers() {
            final int[] PRIMES = {2, 3, 5, 7, 11, 13, 23};
            for (int x : PRIMES) {
                assertTrue(x + " is a prime number", PrimePrinter.isPrimeNumber(x));
            }

        }

        @Test
        public void returnsFalseForNonPrimes() {
            final int[] NON_PRIMES = {4, 6, 12, 21, 36};
            for (int x : NON_PRIMES) {
                assertFalse(x + " is not a prime number", PrimePrinter.isPrimeNumber(x));
            }

        }
    }
}

That's a very nice suggestion. I like the idea of encapsulating a method's testing inside a new class.

I think we should give it a try on the next tests. Let's keep evolving -- there is really no right or wrong.

@gsears I'll leave the unit tests from WEEK 2 with you then, deal? It's very time consuming; TDD should be the mindset from now on so we don't need to come back.

[BelfDev]

@gsears do you plan on implementing the test coverage for week 2?