테스트 주도 개발
이다. 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다. 이 방법을 만든 Kent Beck은 TDD가 단순한 설계를 장려하고 자신감을 불어넣어 준다고 했다!처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문에 개발 속도가 느려진다고 생각하는 사람이 많다. 하지만 야곰이 말하길, 무작정 코드만 짜는 것이 더 비효율적이라고 했다! 생각해보면, 무작정 코드를 쓴다고해서 그게 완벽한 코드도 아니고 오류는 항상 발생을 하는데 TDD 방식을 적용한다고 무조건 시간이 더 걸리는 건 아닐 것 같다. 익숙해지면 오히려 더 좋을지도?
함수의 매개변수와 마찬가지로, init 매개변수도 init 내에서 사용할 매개변수 이름과 초기화가 될 때 사용할 인수 레이블을 모두 가질 수 있다!
init(_ items: [Int]) {
self.items = items
}
// 오늘 활동학습 할 때, 이부분이 이해가 잘 안가서 찾아봤음.
// 지정해서 초기화를 할 수 있구나,, 와일드카드 사용이 익숙치 않아서 사용할때 헷갈린당ㅎ
var stockOfFruit: [Fruit: Int] {
fruitStore.stockOfFruit
}
// 프로젝트에서 사용한 연산프로퍼티. 코드가 한줄이라 return은 생략해주었다.
var name: Type {
get { //getter (다른 저장 연산프로퍼티의 값을 얻거나 연산하여 리턴할 때 사용)
statements
return expr
}
set(name) { //setter (다른 저장프로퍼티에 값을 저장할 때 사용)
statements
}
}
연산 프로퍼티는 값을 저장하는 프로퍼티가 아니라서 타입 추론을 통해 타입을 알 수 없다. 사용할 때는 항상 타입을 명시해주어야하고 어떤 타입의 값을 받아서 다른 저장 프로퍼티에 저장할 것인지, 어떤 값을 리턴해줄 것인지 명시해야한다!! 왕중요!!
연산 프로퍼티는 어떠한 값을 저장하는 것이 아니기 때문에, 타입 추론을 통해 형식을 알 수 없어서, 반드시 선언할 때 타입 어노테이션을 통해 자료형을 명시해야 한다!! 그리고 선언된 자료형 뒤에 {} 를 붙이는 것이 연산 프로퍼티의 사용법이다. 따라서, 내가 어떤 타입의 값을 받아서 다른 저장 프로퍼티에 저장할 것인지, 어떤 타입의 값을 리턴할 것인지를 명시해주어야 함!!!
getter는 말 그대로 "얻는" 것임!
따라서 어떤 저장 프로퍼티의 값을 연산해서 return할 것인지, return 구문이 항상 존재해야 함
setter는 말 그대로 "설정"하는 것임!
따라서 파라미터로 받은 값을 어떤 저장 프로퍼티에 어떻게 설정할 것인지를 구현함!!
[기술면접] TDD(Test-Driven-Development) 방법론에 대해서