테스트 주도 개발 (Test Driven Development) 제 1편!

평소 궁금했던 테스트 주도 개발(Test-Driven Development)대한 책을 읽고, 배웠던 점을 블로그 포스트로 정리해보고자 한다.

책은 최범균 저 테스트 주도 개발 시작하기를 읽었다!



🔷 TDD 시작

🔶 TDD 이전의 개발

TDD Test-Driven Development, 즉 테스트 주도 개발을 배우기 전에, 개발했던 방식은 주로 다음과 같다.

1 . 만들 기능에 대해 설계를 고민한다. 어떤 클래스와 인터페이스를 도출할지 고민하고 각 타입에 어떤 메서드를 넣을지 시간을 들여 생각한다.

2 . 과정1을 수행하면서 구현에 대해서도 고민한다. 대략 어떻게 구현하면 될지 머릿속에 그려 지면 코드를 쓰기 시작한다.

3 . 기능에대한 구현을 완료한 것 같으면 기능을 테스트한다. 이 과정에서 원하는대로 동작하지 않거나 문제가 발생하면 과정2에서 작성한 코드를 디버깅하면서 원인을 찾는다.

위 방식들은 다음과 같은 문제점이 있다.

  • 한번에 작성한 코드가 많은 경우 디버깅하는 시간이 길어진다.

  • 디버깅을 위한 로그 메세지를 추가하거나 IDE에서 제공하는 디버거를 이용해 코드를 따라가며 코드를 분석해야 한다.

  • 최초에 코드를 작성한 시간보다 버그를 찾는 시간이 더 오래걸리는 경우도 있다.

한 번에 구현하는 코드가 많을수록 디버깅 할 때 스트레스가 높아진다.



🔶 TDD 란?

TDD는 테스트부터 시작한다.

구현을 먼저 하고 나중에 테스트하는 것이 아니라 먼저 테스트 를 하고 그다음에 구현한다.

구현 코드가 없는데 어떻게 테스트할 수 있을까?

여기서 테스트를 먼저 한다는 것은 기능이 올바르게 동작하는지 검증하는 테스트 코드를 작성한다는 것을 의미한다.

기능을 검증하는 테스트 코드를 먼저 작성하고 테스트를 통과시키기 위해 개발을 진행한다.

예를 들어, 계산기에 들어갈 덧셈 기능을 간단한 TDD로 구현한다고 치자.

public class CalculatorTest
{
    public void plus() 
    {
        int result = Calculator.plus(2,3);
        assertEquals(5, result);
    }
}

이 코드를 작성하면 Calculator 클래스가 없다는 컴파일 에러가 발생한다.

아직 Calculator 클래스를 작성하지 않았으니 당연히 컴파일 에러가 발생해야 한다.

컴파일 에러를 없애기 전에 코드를 살펴보자.

눈여겨볼 코드는 3행이다. 3행은 아직 존재하지 않는 Calculator 클래스와 plus 메서드를 사용해서 작성했다.

덧셈 기능을 제공하는 클래스와 메서드는 어떤 이름을 가지면 좋을까 고민해서 Calculator와 plus라는 이름을 정했다.

  • 메서드 이름은 plus or sum?

  • 덧셈 기능을 제공하는 메서드는 파라미터가 몇 개여야 할까? 파라미터의 타입은? 반환 할 값은?

  • static method or instance method?

  • 이 메서드를 가진 클래스의 이름은?


덧셈 기능이 올바르게 동작하는지 검증하는 테스트 코드를 작성했지만 아직 실행할 수는 없다.

컴파일 에러가 나기 때문이다.

컴파일 에러를 없애기 위해 일단 Calculator 클래스를 생성하고 0리턴하는 plus() 메서드를 추가하자.

public class Calculator 
{
    public static int plus(int a1, int a2) 
    {
        return 0;
    }
}

이 테스트를 통과시키는 가장 쉬운 방법은 무엇일까? 그것은 바로 plus() 메서드를 다음과 같이 구현하는 것이다.

public class Calculator 
{
    public static int plus(int a1, int a2) 
    {
        return 5;
    }
}

처음에 TDD를 접할 때는 이런 작은 단계를 차근차근 밟아 나가야 한다.

아무튼, 이런식으로 코드를 작성하면 테스트에 통과할 수 있을 것이다. 테스트에 통과했으니 검증 코드를 하나 더 추가하자.

public class CalculatorTest
{
    public void plus() 
    {
        int result = Calculator.plus(2,3);
        assertEquals(5, result);
        assertEquals(10, Calculator.plus(2,8));
    }
}

경우의 수를 하나 더 추가했다. 당연하게도, 위 코드는 테스트에 통과하지 못한다.

2+3과 2+8을 모두 통과시키도록 코드를 수정해야 한다.

public class Calculator 
{
    public static int plus(int a1, int a2) 
    {
        if(a1 == 2 && a2 == 3)
        {
            return 5;
        }
        else 
        {
            return 10;
        }
    }
}

구현 로직이 단순하지 않을때에는 위 예처럼 점진적으로 구현을 완성해 나가야한다.

하지만 덧셈 로직은 간단하므로, 아래와 같이 메서드를 수정했다.

public class Calculator 
{
    public static int plus(int a1, int a2) 
    {
        return a1 + a2;
    }
}


뎃셈 기능을 완료했는데, 아직 하나가 남았다. 바로 테스트가 완료된 코드를 배포될 코드에서 추가하는 것이다.

사실 나는 C# 개발시 적용할 수 있는 TDD에 대해 관심이 있었는데,

참고한 책에서는 Java를 사용하고 있어 Java에 대한 예로 작성한다.

추후, C#에서 사용하는 TDD도구(.NET Framework 단위 테스트 프로젝트)와,

더 나아가 Unit에서 사용할 수 있는 TDD도구(Unity Test Runner)에 대해 알아보도록 한다.

코드 경로를 보면 Calculator.java 파일이 src/test/java 소스 폴더에 위치한 것을 알 수 있다.

처음에 Calculator 클래스를 src/main/java 소스 폴더에 만들어도 되지만 아직 완성된 기능이 아니어서 src/test/java 소스 폴더에 넣었다.

그러나, 덧셈 기능을 완료했으므로 Calculator 클래스를 src/test/java 소스 폴더에서

src/main/java 소스 폴더로 이동시켜서 배포 대상에 포함시킨다.

완성한 코드는 src/test/java에서 src/main/java로 옮긴다


앞서 TDD는 기능을 검증하는 테스트 코드를 먼저 만든다고 했다.

덧셈 예제에서는 덧셈 기능을 검증하는 테스트 코드를 먼저 작성했다.

  • 테스트 대상이 될 클래스 이름, 메서드 이름, 파라미터 개수, 리턴 타입을 고민했다.

  • 새로운 객체를 생성할지 아니면 정적 메서드로 구현할지 등을 고민했다. (이런 고민 과정은 실제 코드를 설계하는 과정과 유사하다.)

  • 테스트 코드를 작성한 뒤에는 컴파일 오류를 없애는 데 필요한 클래스와 메서드를 작성했다.

그런 뒤 바로 테스트를 실행했고 테스트에 실패했다.

  • 실패한 이유를 확인했다.

  • 단순히 3을 리턴해서 테스트를 통과할 만큼만 코드를 구현했다.

  • 실패한 테스트를 통과시킨 뒤에 새로운 테스트를 추가했고 다시 그 테스트를 통과시키기 위한 코드 를 작성했다.

이런 식으로 TDD는 테스트를 먼저 작성하고 테스트에 실패하면 테스트를 통과 시킬 만큼 코드를 추가하는 과정을 반복하면서 점진적으로 기능을 완성해 나간다.



🔶 TDD 예 : 암호 검사기

조금 더 현실적인 기능을 TDD로 구현해보자.

이번에 TDD로 구현할 기능은 암호 검사기이다.

암호 검사기는 문자열을 검사해서 규칙을 준수하는지에 따라 암호를 약함, 보통, 강함으로 구분한다.

살펴볼 예제는 다음 규칙을 이용해서 암호를 검사할 것이다.

  • 검사할규칙은다음세가지이다.

    • 길이가 8글자 이상

    • 0부터 9사이의 숫자를포함

    • 대문자포함

  • 세 규칙을 모두 충족하면 암호는 강함이다.

  • 2개의 규칙을 충족하면 암호는 보통이다.

  • 1개 이하의 규칙을 충족하면 암호는 약함이다.


먼저 테스트할 기능의 이름을 정해보자. 약함, 보통, 강함은 암호 강도라고 볼 수 있으므로,

이를 코드로 표현을 위해서는 PasswordStrength를 선택한다.

이제 검사를 한다는 의미를 표현을 찾아본다.

검색해보니 Checker보다는 Meter를 더 많이 사용하는 것을 알게 되었다.

따라서 이러한 기능을 테스트할 클래스의 이름으로 암호 강도 측정기를 뜻하는 PasswordStrengthMeter를 선택했다.

public class PasswordStrengthMeterTest 
{ 
    @Test
    void name() 
    {
    } 
}


💠 [TDD 예 : 암호 검사기] 첫 번째 테스트 : 모든 규칙을 충족하는 경우

이제 진짜 첫 번째 테스트를 만들어보자. 여기가 중요하다!

첫 번째 테스트를 잘 선택하지 않으면 이후 진행 과정이 순탄하게 흘러가지 않는다.

첫 번째 테스트를 선택할 때에는 가장 쉽거나 가장 예외적인 상황을 선택해야 한다.

현재 기능 명세에서 가장 쉽거나 가장 예외적인 것은 무엇일까?

  • 모든 규칙을 충족하는 경우

  • 모든 조건을 충족하지 않는 경우


이 중에서 어떤 경우가 시작하기에 좋을까?

먼저 모든 조건을 충족하지 않는 경우를 생각해 보자.

모든 조건을 충족하지 않는 테스트를 통과시키려면 각 조건을 검사하는 코드를 모두 구현해야 할 것이다!

한 번에 만들어야 할 코드가 많아지므로 첫 번째 테스트 코드를 통과하는 시간도 길어 진다.

이는 사실상 구현을 다 하고 테스트를 하는 방식과 다르지 않다.


모든 규칙을 충족하는 경우는 어떨까? 테스트를 쉽게 통과시킬 수 있다.

각 조건을 검사하는 코드를 만들지 않고 강함에 해당하는 값을 리턴하면 테스트에 통과할 수 있다.

그래서 모든 조건을 충족하는 경우를 먼저 테스트 코드로 작성해 보자.

책을 읽을땐, 같은 논리로 각 조건을 검사하는 코드를 만들지 않고

약함에 해당하는 값을 리턴하면 되는거 아닌가? 라고 생각했다.

그러나 이 부분에 대해서는 다른 챕터에서 설명이 잘 되어 있어, 여기서는 넘기도록 한다.


‘암호가 모든 조건을 충족하면 암호 강도는 강함이어야 함’을 의미하는 문장을 테스트 메 서드의 이름으로 사용하고 싶다.

If the password meets all the criteria then the strength should be strong 이라는 문장이 적당해보인다.

그런데 메서드이름으로 사용하기에는 문장이 너무 길고, 메서드 이름에 공백을 포함할 수 없다.

그래서 다음과 같이 간단한 이름을 사용하기로 했다.

public class PasswordStrengthMeterTest 
{ 
    @Test
    void meetsAllCriteria_Then_Strong() 
    {
        // 코드 작성 필요
    } 
}


테스트 코드를 작성할 차례이다. 테스트 코드는 다음과 같은 형태를 갖게 될 것이다.

PasswordStrengthMeter meter = new PasswordStrenghMeter();
값타입 결과 = meter.meter("ab12!@AB"); 
assertEquals(기댓값, 결과);

이 코드를 완성하려면 PasswordStrengthMeter의 meter() 메서드의 리턴 타입을 결정해야 한다.

결과값은 암호의 강도이므로 int 타입을 사용할 수 있다. 예를 들어 0이면 약함, 1이면 보통, 2이면 강함이라고 할 수 있다.

또는 PasswordStrength.STRONG 형태의 열거 타입을 사용할 수도 있다.

2와 같은 값보다는 PasswordStrength.STRONG와 같은 열거 타입 값이 암호 강도를 더 잘 표현하므로

이 예제에서는 테스트 코드를 아래와 같이 작성했다.

public class PasswordStrengthMeterTest 
{ 
    @Test
    void meetsAllCriteria_Then_Strong() 
    {
        PasswordStrengthMeter meter = new PasswordStrengthMeter(); 
        Passwordstrength result = meter.meter("ab12!@AB"); 
        assertEquals(PasswordStrength.STRONG, result);
    } 
}

메서드 이름에 어떤 부분은 camel case이고, 어떤 부분은 _를 사용하고 있는데,

이 부분 또한 뒤에서 설명 될 것으로 보인다!

먼저 할 일은 컴파일 에러를 없애는 것이다. 그래야 테스트를 실행할 수 있다.

public enum Passwordstrength 
{ 
    STRONG
}

또한 PasswordStrengthMeter 클래스를 작성해서 컴파일 에러를 마저 없앤다.

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        return null;
    }
}

컴파일 에러를 없앴으니 테스트를 실행할 수 있다.

하지만 기대한 값이 PasswordStrength.STRONG인데 실제 값은 null이어서 테스트에 실패한다.

이걸 통과하는 방법은 간단하다.

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        return PasswordStrength.STRONG;
    }
}

그럼 테스트틀 통과할 수 있다.


meetsAllCriteria_Then_Strong() 테스트 메서드에 모든 규칙을 충족하는 예를 하나 더 추가 하자.

다음은 추가한 결과이다.

public class PasswordStrengthMeterTest 
{ 
    @Test
    void meetsAllCriteria_Then_Strong() 
    {
        PasswordStrengthMeter meter = new PasswordStrengthMeter(); 
        Passwordstrength result = meter.meter("ab12!@AB"); 
        assertEquals(PasswordStrength.STRONG, result);
        Passwordstrength result2 = meter.meter("abc1!Add"); 
        assertEquals(PasswordStrength.STRONG, result2);
    } 
}

코드를 실행해도, 역시 테스트틀 통과한다.

📌 콩글리쉬 VS 한글 메서드

필자는 영어 구사 능력이 떨어져서 메서드 작명에 어려움을 느낄 때가 많다.

요즘은 번역기가 좋아져서 예전보다 작명 시간이 줄었지만, 여전히 알맞은 영어 이름을 찾는 과정은 필자를 힘들게 한다.

특히 테스트 메서드의 이름은 길어질 때가 많아 더 힘들다.

영어 문장이 길어지면 나중에 다시 메서드 이름을 봤을 때 해석하는 과정이 길어지므로 메서드의 의미를 파악하는 데 시간이 걸린다.

그래서 필자는 테스트 메서드 이름을 한글로 작성해서 가독성을 높이곤 한다.

물론 동료 개발자 중에 한글을 모르는 사람이 없으면 할 수 없다.


💠 [TDD 예 : 암호 검사기] 두 번째 테스트 : 길이만 8글자 미만이고 나머지 조건은 충족하는 경우

두 번째 테스트 메서드를 추가하자.

이번에 테스트할 대상은 패스워드 문자열의 길이가 8글자 미만이고 나머지 조건은 충족하는 암호이다.

public class PasswordStrengthMeterTest 
{ 
    @Test 
    meetsAllCriteria_Then_Strong()
    {
        //생략
    } 

    @Test
    void meetsOtherCriteria_except_for_Length_Then_Normal() 
    {
        PasswordStrengthMeter meter = new PasswordStrengthMeter();
        Passwordstrength result = meter.meter("ab12!@A");
        assertEquaIs(PasswordStrength.NORMAL, result);
    } 
}

그럼 또 컴파일 에러가 생긴다. enum값을 수정해야 한다.

public enum Passwordstrength 
{ 
    NORMAL, STRONG
}

그럼 컴파일은 되지만, 테스트에 실패한다.

테스트를 통과하기 위해 meter 메서드를 아래와 같이 길이가 8보다 작으면 NORMAL을 리턴하는 코드를 추가한다.

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (s.length() < 8)
        {
            return PasswordStrength.NORMAL;
        }
        return PasswordStrength.STRONG;
    }
}

코드를 수정하고 테스트를 진행해보자. 그럼 통과한 모습을 볼 수 있다!

다른 테스트 코드도 추가하고, 테스트를 실행해보자.

public class PasswordStrengthMeterTest 
{ 
    @Test 
    meetsAllCriteria_Then_Strong()
    {
        //생략
    } 

    @Test
    void meetsOtherCriteria_except_for_Length_Then_Normal() 
    {
        PasswordStrengthMeter meter = new PasswordStrengthMeter();
        Passwordstrength result = meter.meter("ab12!@A");
        assertEquaIs(PasswordStrength.NORMAL, result);
        Passwordstrength result2 = meter.meter("Ab12!c");
        assertEquals(PasswordStrength.NORMAL, result2);
    } 
}


💠 [TDD 예 : 암호 검사기] 세 번째 테스트 : 숫자를 포함하지 않고 나머지는 충족하는 경우

세 번째 테스트 메서드를 추가하자.

이번 테스트 대상은 숫자를 포함하지 않고 나머지 조건은 충족하는 암호이다.

이 암호도 보통 강도를 가져야 한다. 이를 위한 테스트 코드를 추가하자.

@Test
void meetsOtherCriteria_except_for_Number_Then_Normal() 
{
    PasswordStrengthMeter meter = new PasswordStrengthMeter();
    Passwordstrength result = meter.meter("ab!@ABqwer");
    assertEquals(PasswordStrength.NORMAL, result);
}

이 테스트를 통과하는 방법은 어렵지 않다.

암호가 숫자를 포함했는지를 판단해서 포함하지 않은 경우 NORMAL을 리턴하게 구현하면 된다.

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (s.length() < 8)
        {
            return PasswordStrength.NORMAL;
        }
        bool containsNum = meetsContainingNumberCriteria(s);
        if(contatinsNum == false)
        {
            reutnr 
        }
        return PasswordStrength.STRONG;
    }

    private bool meetsContainingNumberCriteria(string s)
    {
        foreach (char ch in s.toCharArray()) 
        {
            if(ch >='0' && ch<='9')
            { 
                return true;
            } 
        }
        return false;
    }
}

코드를 수정했으니 테스트를 실행한다. 올바르게 리팩토링했다면 테스트에 통과할 것이다.


💠 [TDD 예 : 암호 검사기] 코드 정리 : 테스트 코드 정리

세 개의 테스트 메서드를 추가했다. 각 테스트 메서드를 보면 다음과 같은 형태를 갖는다.

@Test
void 메서드이름() {
    PasswordStrengthMeter meter = new PasswordStrengthMeter(); 
    Passwordstrength result = meter.meter(암호); 
    assertEquals(Passwordstrength.값, result);
}

테스트 코드도 코드이기 때문에 유지보수 대상이다.

즉 테스트 메서드에서 발생하는 중복을 알맞게 제거하거나 의미가 잘 드러나게 코드를 수정할 필요가 있다.

코드의 중복을 없애 보자. 지금은 각 메서드에서 PasswordStrengthMeter 객체를 생성하고 있는데,

다음 코드처럼 필드에서 생성하도록 수정할 수 있다.

public class PasswordStrengthMeterTest 
{ 
    private PasswordStrengthMeter meter = new PasswordStrengthMeter();

    @Test 
    meetsAllCriteria_Then_Strong()
    {
        Passwordstrength result = meter.meter("abl2!@AB’’);
        assertEquals(PasswordStrength.STRONG, result); 
        // ...생략
    } 

    @Test
    void meetsOtherCriteria_except_fbr_Length_Then_Normal() 
    {
        Passwordstrength result = meter.meter("abl2!@A"); 
        assertEquals(PasswordStrength.NORMAL, result); 
        // ...생략
    }

    @Test
    void meetsOtherCriteria_except_for_Number_Then_Normal() 
    {
        Passwordstrength result = meter.meter("ab!@ABqwer"); 
        assertEquals(PasswordStrength.NORMAL, result); 
        // ...생략
    }
}


없앨 수 있는 코드 중복이 하나 더 있다.

바로 암호 강도 측정 기능을 실행하고 이를 확인하는 코드이다.

이 코드의 형식은 다음과 같다.

Passwordstrength result = meter.meter(암호);
assertEquals(기댓값, result);

이런 부류의 중복은 메서드를 이용해서 제거하도록 한다.

private void assertStrength(string password, Passwordstrength expStr) 
{
    Passwordstrength result = meter.meter(password);
    assertEquals(expStr, result);
}

이 제 테스트 메서드의 코드가 assertStrength 메서드를 사용하도록 바꾼다.

public class PasswordStrengthMeterTest 
{
    private PasswordStrengthMeter meter = new PasswordStrengthMeter();

    private void assertStrength(string password, Passwordstrength expStr) 
    {
        Passwordstrength result = meter.meter(password);
        assertEquals(expStr, result);
    }

    @Test
    void meetsAllCriteria_Then_Strong() 
    {
        assertStrength("abl2!@AB", PasswordStrength.STRONG);
        assertStrength("abcl!Add", PasswordStrength.STRONG);
        // ...다른 두 테스트 메서드도 동일하게 변경
    }
}


💠 [TDD 예 : 암호 검사기] 네 번째 테스트 : 값이 없는 경우

테스트 코드를 작성하는 과정에서 아주 중요한 테스트를 놓친 것을 발견했다.

바로 값이 없는 경우를 테스트하지 않은 것이다.

예를 들어 meter 메서드에 null을 전달하면 NullPointerException이 발생하게 된다.

테스트를 추가해보자. null을 입력할 경우 암호 강도 측정기는 어떻게 반응해야 할까? 필자는 두 가지 안이 떠올랐다.

  • IllegalArgumentException을 발생한다.
  • 유효하지 않은 암호를 의미하는 PasswordStrength.INVALID를 리턴한다.

이 책에서는 이 중에서 두 번째 방법을 선택해보자. 역시 테스트 코드를 추가하고, enum 값을 추가한다.

public class PasswordStrengthMeterTest 
{
    // 생략

    @Test
    void nullInput_Then_Invalid() 
    {
        assertStrength(null, PasswordStrength.INVALID);
        assertStrength("", PasswordStrength.INVALID);
    }
}

public enum Passwordstrength 
{ 
    INVALID, NORMAL, STRONG
}

테스트를 실행하면, 당연하게도 NPE가 발생해서 테스트에 실패하게 된다.

다음과 같은 코드를 PasswordStrengthMeter 에 추가한다.

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (string.IsNullOrEmpty(s) == true) return PasswordStrength.INVALID;
        if (s.length() < 8)
        {
            return PasswordStrength.NORMAL;
        }
        bool containsNum = meetsContainingNumberCriteria(s);
        if(contatinsNum == false)
        {
            reutnr 
        }
        return PasswordStrength.STRONG;
    }

    // ...생략
}

맞게 구현했다면, 지금까지 작성한 테스트가 모두 통과할 것이다.


💠 [TDD 예 : 암호 검사기] 다섯 번째 테스트 : 대문자를 포함하지 않고, 나머지 조건을 충족하는 경우

다음 추가할 테스트는 대문자를 포함하지 않고 나머지 조건은 충족하는 경우이다.

public class PasswordStrengthMeterTest 
{
    // 생략

    @Test
    void meetsOtherCriteria_except_for_Uppercase_Then_Normal() 
    {
        assertStrength("ab12!@df", PasswordStrength.NORMAL);
    }
}

테스트가 실패한다. 코드를 수정한다.

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (string.IsNullOrEmpty(s) == true) return PasswordStrength.INVALID;
        if (s.length() < 8) 
        {
            return PasswordStrength.NORMAL;
        }
        bool containsNum = meetsContainingNumberCriteria(s);
        if (containsNum == false) 
        {
            return PasswordStrength.NORMAL;
        }
        bool containsUpper = meetsContainingUppercaseCriteria(s); 
        if (containsUpper == false) 
        {
            return PasswordStrength.NORMAL;
        }
        return PasswordStrength.STRONG;
    }

    private bool meetsContainingNumberCriteria(string s)
    {
        bool containsUpper = false;
        foreach (char ch in s.toCharArray()) 
        {
            if (Char.IsUpper(ch)) 
            { 
                containsUpper = true;
                break;
            }
        }
        return containsUpper;
    }
    // ...생략
}


💠 [TDD 예 : 암호 검사기] 여섯 번째 테스트 : 길이가 8글자 이상인 조건만 충족하는 경우

이제 어떤 경우를 테스트해야 하나?

남은 것은 한 가지 조건만 충족하거나 모든 조건을 충족하지 않는 경우이다.

이 중에서 먼저 길이가 8글자 이상인 조건만 충족하는 경우를 진행 해 보자. 이 경우 암호 강도는 약함이다.

public class PasswordStrengthMeterTest 
{
    // 생략

    @Test
    void meetsOnlyLengthCriteria_Then_Weak() 
    {
        assertStrength("abcdefghijk", PasswordStrength.WEAK);
    }
}

public enum Passwordstrength 
{ 
    WEAK, INVALID, NORMAL, STRONG
}

테스트를 하면, 기대 결과는 WEAK이나, 실행 결과는 NORMAL이어서 테스트에 실패했음을 알 수 있다.

어 떻게 하면 테스트에 통과할 수 있을까? 이 테스트를 통과시키려면 세 조건 중에서 길이 조건은 충족하고

나머지 두 조건은 충족하지 않았을 때 WEAK를 리턴하도록 구현해야 한다.

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (string.IsNullOrEmpty(s) == true) return PasswordStrength.INVALID;
        bool lengthEnough = s.length() >= 8;
        bool containsNum = meetsContainingNumberCriteria(s);
        bool containsUpper = meetsContainingUppercaseCriteria(s);

        if (lengthEnough == true && containsNum == false && containsUpper == false)
        {
            return PasswordStrength.WEAK;
        }

        if (lengthEnough == false) 
        {
            return PasswordStrength.NORMAL;
        }
        if (containsNum == false) 
        {
            return PasswordStrength.NORMAL;
        }
        if (containsUpper == false) 
        {
            return PasswordStrength.NORMAL;
        }
        return PasswordStrength.STRONG;
    }

    // ...생략
}


💠 [TDD 예 : 암호 검사기] 일곱 번째 테스트 : 숫자 포함 조건만 충족하는 경우

다음 테스트는 숫자 포함 조건만 충족하는 경우이다. 이를 검증하기 위한 테스트 코드를 작성한다.

public class PasswordStrengthMeterTest 
{
    // 생략

    @Test
    void meetsOnlyNumCriteria_Then_Weak() 
    {
        assertStrength("12345", PasswordStrength.WEAK);
    }
}

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (string.IsNullOrEmpty(s) == true) return PasswordStrength.INVALID;
        bool lengthEnough = s.length() >= 8;
        bool containsNum = meetsContainingNumberCriteria(s);
        bool containsUpper = meetsContainingUppercaseCriteria(s);

        if (lengthEnough == true && containsNum == false && containsUpper == false)
        {
            return PasswordStrength.WEAK;
        }
        if (lengthEnough == false && containsNum == true && containsUpper == false)
        {
            return PasswordStrength.WEAK;
        }

        if (lengthEnough == false) 
        {
            return PasswordStrength.NORMAL;
        }
        if (containsNum == false) 
        {
            return PasswordStrength.NORMAL;
        }
        if (containsUpper == false) 
        {
            return PasswordStrength.NORMAL;
        }
        return PasswordStrength.STRONG;
    }

    // ...생략
}


💠 [TDD 예 : 암호 검사기] 여덟 번째 테스트 : 대문자 포함 조건만 충족하는 경우

이번에는 대문자 포함 조건만 충족하는 경우를 검증하는 테스트를 추가할 차례다.

public class PasswordStrengthMeterTest 
{
    // 생략

    @Test
    void meetsOnlyNumCriteria_Then_Weak() 
    {
        assertStrength("ABZEF", PasswordStrength.WEAK);
    }
}

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (string.IsNullOrEmpty(s) == true) return PasswordStrength.INVALID;
        bool lengthEnough = s.length() >= 8;
        bool containsNum = meetsContainingNumberCriteria(s);
        bool containsUpper = meetsContainingUppercaseCriteria(s);

        if (lengthEnough == true && containsNum == false && containsUpper == false)
        {
            return PasswordStrength.WEAK;
        }
        if (lengthEnough == false && containsNum == true && containsUpper == false)
        {
            return PasswordStrength.WEAK;
        }
        if (lengthEnough == false && containsNum == false && containsUpper == true)
        {
            return PasswordStrength.WEAK;
        }

        if (lengthEnough == false) 
        {
            return PasswordStrength.NORMAL;
        }
        if (containsNum == false) 
        {
            return PasswordStrength.NORMAL;
        }
        if (containsUpper == false) 
        {
            return PasswordStrength.NORMAL;
        }
        return PasswordStrength.STRONG;
    }

    // ...생략
}



💠 [TDD 예 : 암호 검사기] meter() 메서드 리팩토링

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (string.IsNullOrEmpty(s) == true) return PasswordStrength.INVALID;
        bool lengthEnough = s.length() >= 8;
        bool containsNum = meetsContainingNumberCriteria(s);
        bool containsUpper = meetsContainingUppercaseCriteria(s);

        if (lengthEnough == true && containsNum == false && containsUpper == false)
        {
            return PasswordStrength.WEAK;
        }
        if (lengthEnough == false && containsNum == true && containsUpper == false)
        {
            return PasswordStrength.WEAK;
        }
        if (lengthEnough == false && containsNum == false && containsUpper == true)
        {
            return PasswordStrength.WEAK;
        }

        if (lengthEnough == false) 
        {
            return PasswordStrength.NORMAL;
        }
        if (containsNum == false) 
        {
            return PasswordStrength.NORMAL;
        }
        if (containsUpper == false) 
        {
            return PasswordStrength.NORMAL;
        }
        return PasswordStrength.STRONG;
    }

    private bool meetsContainingNumberCriteria(string s)
    {
        foreach (char ch in s.toCharArray()) 
        {
            if(ch >='0' && ch<='9')
            { 
                return true;
            } 
        }
        return false;
    }

    private bool meetsContainingNumberCriteria(string s)
    {
        bool containsUpper = false;
        foreach (char ch in s.toCharArray()) 
        {
            if (Char.IsUpper(ch)) 
            { 
                containsUpper = true;
                break;
            }
        }
        return containsUpper;
    }
}

메서드로 추출해서 meter() 메서드의 길이를 줄이긴 했지만, 여전히 코드가 복잡 하게 느껴진다.

이 코드를 어떻게 바꾸면 좋을까? 코드의 의미를 잠시 생각해봤다.

if (lengthEnough == true && containsNum == false && containsUpper == false)
{
    return PasswordStrength.WEAK;
}
if (lengthEnough == false && containsNum == true && containsUpper == false)
{
    return PasswordStrength.WEAK;
}
if (lengthEnough == false && containsNum == false && containsUpper == true)
{
    return PasswordStrength.WEAK;
}

이 코드는 세 조건 중에서 한 조건만 충족하는 경우 암호 강도가 약하다는 것을 구현한 것이다.

그렇다! 여기서 if 절은 세 조건 중에서 한 조건만 충족한다는 것을 확인하는 것이다.

그렇다면 다음과 같이 충족하는 조건 개수를 사용하면 어떨까?

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (string.IsNullOrEmpty(s) == true) return PasswordStrength.INVALID;
        int metCount = 0;
        metCount = ( lengthEnough = s.length() >= 8 ) ? (metCount + 1) : metCount;
        metCount = ( meetsContainingNumberCriteria(s) == true) ? (metCount + 1) : metCount;
        metCount = ( meetsContainingUppercaseCriteria(s) == true ) ? (metCount + 1) : metCount;

        if (metCount == 1)
        {
            return PasswordStrength.WEAK;
        }
        if (metCount == 2) 
        {
            return PasswordStrength.NORMAL;
        }
        return PasswordStrength.STRONG;
    }

    // 생략
}


💠 [TDD 예 : 암호 검사기] 아홉 번째 테스트 : 아무 조건도 충족하지 않은 경우

아직 테스트하지 않은 상황이 있다. 바로 아무 조건도 충족하지 않는 암호이다.

이를 검증하기 위한 테스트를 추가한다.

public class PasswordStrengthMeterTest 
{
    // 생략

    @Test
    void meetsNoCriteria_Then_Weak() 
    {
        assertStrength("abc", PasswordStrength.WEAK);
    }
}

원하는 결과는 WEAK인데 실제 결과는 STRONG이다.

코드를 수정하자.

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (string.IsNullOrEmpty(s) == true) return PasswordStrength.INVALID;
        int metCount = 0;
        metCount = ( lengthEnough = s.length() >= 8 ) ? (metCount + 1) : metCount;
        metCount = ( meetsContainingNumberCriteria(s) == true) ? (metCount + 1) : metCount;
        metCount = ( meetsContainingUppercaseCriteria(s) == true ) ? (metCount + 1) : metCount;

        if (metCount <= 1)
        {
            return PasswordStrength.WEAK;
        }
        if (metCount == 2) 
        {
            return PasswordStrength.NORMAL;
        }
        return PasswordStrength.STRONG;
    }

    // 생략
}


💠 [TDD 예 : 암호 검사기] 코드 정리 : 코드 가독성 개선

코드 정리를 할 필요가 있다. 이번 변경 대상은 metCount 변수를 계싼하는 부분이다.

public class PasswordStrengthMeter 
{ 
    public Passwordstrength meter(string s) 
    {
        if (string.IsNullOrEmpty(s) == true) return PasswordStrength.INVALID;
        int metCount = getMetCriteriaCounts(s);

        if (metCount <= 1)
        {
            return PasswordStrength.WEAK;
        }
        if (metCount == 2) 
        {
            return PasswordStrength.NORMAL;
        }
        return PasswordStrength.STRONG;
    }

    private int getMetCriteriaCounts(string s)
    {
        int metCount = 0;
        metCount = ( lengthEnough = s.length() >= 8 ) ? (metCount + 1) : metCount;
        metCount = ( meetsContainingNumberCriteria(s) == true) ? (metCount + 1) : metCount;
        metCount = ( meetsContainingUppercaseCriteria(s) == true ) ? (metCount + 1) : metCount;
        return metCount;
    }
    // 생략
}

meter() 메서드의 가독성이 좋아졌다.

meter() 메서드를 처음보는 개발자도 다음과 같이 코드 를 읽을 수 있다.

  • 암호가 null이거나 빈 문자열이면 암호 강도는 INVALID이다
  • 충족하는 규칙 개수를 구한다.
  • 충족하는 규칙 개수가 1개 이하면 암호 강도는 WEAK이다.
  • 충족하는 규칙 개수가 2개면 암호 강도는 NORMAL이다.
  • 이 외 경우(즉 충족하는 규칙 개수가 2개보다 크면) 암호 강도는 STRONG이다



🔶 TDD 흐름

지금까지 암호 강도 검사 기능을 TDD로 구현했다. 그 과정은 아래와 같다.

TDD는 테스트를 먼저 작성하고 테스트를 통과시킬 만큼 코드를 작성하고
리팩토링으로 마무리 하는 과정을 반복한다.

TDD는 기능을 검증하는 테스트를 먼저 작성한다.

작성한 테스트를 통과하지 못하면 테스트를 통과할 만큼만 코드를 작성한다.

테스트를 통과한 뒤에는 개선할 코드가 있으면 리팩토링한다. 리팩토링을 수행한 뒤에는 다시 테스트를 실행해서 기존 기능이 망가지지 않았는지 확인한다.

이 과정을 반복하면서 점진적으로 기능을 완성해 나가는 것, 이것이 전형적인 TDD의 흐름이다.


💠 테스트가 개발을 주도

테스트 코드를 먼저 작성하면 테스트가 개발을 주도하게 된다.

앞서 암호 검사 기능을 떠올려 보자. 가장 먼저 통과해야 할 테스트를 작성했다.

테스트를 작성하는 과정에서 구현을 생각하지 않았다.

단지 해당 기능이 올바르게 동작하는지 검증할 수 있는 테스트 코드를 만들었을 뿐이다.

테스트를 추가한 뒤에는 테스트를 통과시킬 만큼 기능을 구현했으며,

지금까지 작성한 테스트를 통과할 만큼만 구현을 진행했고, 아직 추가하지 않은 테스트를 고려해서 구현하지 않았다.

테스트 코드를 만들면 다음 개발 범위가 정해진다.

테스트 코드가 추가되면서 검증하는 범위가 넓어질수록 구현도 점점 완성되어간다. 이렇게 테스트가 개발을 주도해 나간다.


💠 지속적인 코드 정리

구현을 완료한 뒤에는 리팩토링을 진행했다.

리팩토링할 대상이 눈에 들어오면 리팩토링을 진행해서 코드를 정리했고,

스트 코드 자체도 리팩토링 대상에 넣었다.

TDD는 개발 과정에서 지속적으로 코드 정리를 하므로

코드 품질이 급격히 나빠지지 않게 막아 주는 효과가 있다.

이는 향후 유지보수 비용을 낮추는데 기여한다.


💠 빠른 피드백

TDD가 주는 이점은 코드 수정에 대한 피드백이 빠르다는 점이다.

새로운 코드를 추가하거나 기존 코드를 수정하면 테스트를 돌려서

해당 코드가 올바른지 바로 확인할 수 있다.

이는 잘못 된 코드가 배포되는 것을 방지한다.




🔶 다음 편에 계속…!

🚩 다음편 : TDD | 테스트 코드의 구성과 테스트 대역