- 내가 담당이라서 혼자서 유지보수할 수도 있지만, 다른 개발자가 유지보수하거나 업데이트할 수 있다. 그렇기 때문에 유지 보수성을 위해 Clean Code로 작성해야 한다.
# 내부 구현 사항을 테스트하지 않는다.
- 기능 검증
테스트는 주로 기능이 올바르게 작동하는지를 검증하는 데 초점을 맞춰야 한다. 내부 구현에 의존하게 되면, 코드 변경 시 테스트가 불필요하게 실패할 수 있다.
- 유지보수 용이성
내부 구현 로직 변경되더라도, 외부에서 제공하는 API나 기능이 동일하다면 테스트가 통과해야 한다. 내부 구현을 테스트하면, 사소한 변경에도 테스트를 수정해야 한다.
- 테스트의 독립성
테스트는 각 모듈이 독립적으로 작동하는지를 검증해야 한다. 내부 구현에 대한 의존성은 테스트 간의 독립성을 해칠 수 있다.
- 리팩토링의 용이성
코드의 리팩토링이 필요할 때, 내부 구현이 테스트에 포함되어 있다면 리팩토링 과정이 복잡해질 수 있다. 반면, 외부 인터페이스만 테스트하고 있다면, 내부 구현을 자유롭게 수정할 수 있다.
따라서, 테스트는 주로 외부 인터페이스나 결과를 검증하는 방식으로 작성하는 것이 좋다. 이는 유지보수성과 안정성을 높이고, ,코드의 품질을 개선하는 데 기여한다.
예시로 살펴보자!
예시 1: 계산기 모듈
// 계산기 모듈
class Calculator {
add(a, b) {
return a + b; // 내부 구현
}
}
// 테스트 코드
test('두 수를 더한다', () => {
const calculator = new Calculator();
expect(calculator.add(2, 3)).toBe(5); // 결과 검증
});
- add 메서드의 내부 구현(단순 덧셈)을 테스트하는 것이 아니라, 입력된 두 수의 합이 올바른지를 검증한다.
예시 2 : 사용자 인증 모듈
// 사용자 인증 모듈
class AuthService {
login(username, password) {
// 내부 로직: DB에서 사용자 검증
return username === 'user' && password === 'pass'; // 내부 구현
}
}
// 테스트 코드
test('올바른 자격 증명으로 로그인', () => {
const authService = new AuthService();
expect(authService.login('user', 'pass')).toBe(true); // 결과 검증
});
- login 메서드의 내부 로직(사용자 검증 방식)을 테스트하지 않고, 올바른 자격 증명으로 로그인이 성공하는지를 검증한다.
예시 3 : 데이터 조회 모듈
// 데이터 조회 모듈
class DataService {
fetchData() {
// 내부 구현: API 호출 및 데이터 가공
return fetch('https://api.example.com/data').then(response => response.json());
}
}
// 테스트 코드
test('데이터를 성공적으로 조회', async () => {
const dataService = new DataService();
const data = await dataService.fetchData();
expect(data).toHaveProperty('key'); // 결과 검증
});
- fetchData 메서드의 API 호출 및 데이터 가공 로직을 테스트하지 않고, 반환된 데이터가 특정 속성을 가지고 있는지를 검증한다.
# 테스트 코드에서 반복적으로 사용되어지는 코드가 있다면 재사용성을 높이기 위해서 별도의 함수나 테스트용 클래스를 만들어서 재사용성을 높여야 한다.
