원문: https://blog.ploeh.dk/2013/03/11/listen-to-trivial-tests/
Craftmanship
My blog post was a reaction to Robert C. Martin's post on The Pragmatics of TDD. One of the qualities I've always appreciated of people like Robert C. Martin and Martin Fowler is that they consistently explain the reasoning behind their actions. The part of The Pragmatics of TDD that caused me to react was that it contains practices that aren't explained.
나의 블로그 게시물은 로버트 C에 대한 반응이었다. TDD의 실용주의에 대한 마틴의 글. 내가 로버트 C 같은 사람들에게 항상 고마워했던 자질 중 하나. 마틴과 마틴 파울러는 그들이 일관되게 그들의 행동 뒤에 숨겨진 이유를 설명한다는 것이다. 제가 반응하게 된 TDD의 실용주의 부분은 그것이 설명되지 않은 관행을 포함하고 있다는 것입니다.
Notice that Robert C. Martin takes time to explain why he doesn't unit test UI code (too much fiddling is involved). To me, that's a fully satisfactory explanation, so I didn't react against that at all. On the other hand, he states that he doesn't write tests against obviously trivial members, but no satisfactory explanation is given.
로버트 C.를 주목하라. Martin은 UI 코드를 유닛 테스트하지 않는 이유를 설명하는 데 시간이 걸립니다(너무 많은 조작이 포함됨). 나에게 그것은 충분히 만족스러운 설명이기 때문에 나는 그것에 대해 전혀 반응하지 않았다. 반면, 그는 명백하게 사소한 member들을 상대로 시험을 쓰지 않는다고 말하지만, 만족스러운 설명은 제공되지 않는다.
Robert C. Martin has been programming for more than 40 years, and been doing TDD longer than me, so I have no doubt that this pragmatic approach works for him (as well as for many of the people who disagree with my previous post). However, if, for the sake of argument, we accept the Dreyfus model of skill acquisition, Robert C. Martin is clearly an Expert. He uses intuition and tacit knowledge to make appropriate decisions. Normally, as in Clean Code, he does a great job of making this tacit knowledge explicit, but in this case I found the explanation was missing, so I wanted to explore that question.
로버트 C 마틴은 40년 이상 프로그래밍을 해왔고, 나보다 TDD를 더 오래 해왔기 때문에, 나는 이 실용적인 접근법이 그에게 효과가 있다는 것을 의심하지 않습니다. 그러나 논쟁을 위해, 우리가 기술 습득의 드레퓌스 모델인 로버트 C를 받아들인다면, 마틴은 분명히 전문가입니다. 그는 적절한 결정을 내리기 위해 직관과 암묵적인 지식을 사용합니디ㅏ. 평소에는 클린코드에서처럼 이 암묵적인 지식을 명시적으로 표현하는 일을 잘 하지만, 이 경우에는 설명이 빠져 있다는 것을 발견했기 때문에 저는 그 질문을 탐구하고 싶었습니다.
Perhaps I was a bit high on laying out a logical argument. Yesterday, my wife (who's not at all a programmer) kindly read through the article and let me know that my language could have been less aggressive. It could, and I apologize if I offended anyone - particularly Robert C. Martin from whom I've learned so much.
아마도 나는 논리적인 주장을 펴는 것에 약간 흥분했을 것이다. 어제, 제 아내(전혀 프로그래머가 아닌)는 친절하게 기사를 읽었고 제 언어가 덜 공격적일 수도 있었다는 것을 알려주었습니다. 그럴 수도 있고, 특히 로버트 C를 불쾌하게 했다면 사과드립니다. 마틴에게 많은 것을 배웠다.
Most of all, though, I think I could have stated my motivation and context clearer.
하지만 무엇보다 동기와 맥락을 더 명확하게 말할 수 있었다고 생각한다.
As I have previously stated on Twitter, I have come to the realization that I'm a Programmer more than I'm a Developer. While I love software, I love code more. If you ask my past employers and customers, they will tell you that I can get stuff done, too. However, I often code just to learn. This is an aspect of Software Craftmanship that is sometimes overlooked: Yes, we want to ship working software. However, we must always strive to become better at our craft, and that means practice. That means writing code for code's sake. That means obsessing over details.
내가 트위터에서 이전에 말했듯이, 나는 개발자라기보다는 프로그래머라는 것을 깨달았다. 나는 소프트웨어를 사랑하지만 코드를 더 사랑한다. 만약 당신이 나의 과거 고용주들과 고객들에게 묻는다면, 그들은 당신에게 나도 일을 해낼 수 있다고 말할 것이다. 하지만, 나는 종종 단지 배우기 위해 코딩을 한다. 이것은 때때로 간과되는 소프트웨어 크래프트맨십의 한 측면입니다. 네, 작동 중인 소프트웨어를 선적하고 싶습니다. 하지만, 우리는 항상 우리의 기술을 더 잘하기 위해 노력해야 하고, 그것은 연습을 의미한다. 그것은 코드를 위해 코드를 작성하는 것을 의미한다. 그것은 세부적인 것에 집착하는 것을 의미한다.
It also means thinking about aspects of programming that many people take for granted, such as properties.
그것은 또한 프로퍼티와 같이 많은 사람들이 당연하게 여기는 프로그래밍의 측면에 대해 생각하는 것을 의미한다.
Tests provide feedback
Several people attacked my previous post because they think it's not practical and that it puts TDD in a bad light. Actually, I think it puts TDD in a splendid light because it made me explicitly realize something that I've implicitly 'known' for a long time: we use way too many properties in our code.
몇몇 사람들은 내 이전 게시물이 실용적이지 않고 TDD를 나쁘게 만든다고 생각하기 때문에 그것을 공격했다. 사실, TDD는 내가 오랫동안 암묵적으로 '알고 있던' 것을 분명히 깨닫게 해주었기 때문에, 우리는 코드에 너무 많은 속성을 사용한다.
As always, we should take to heart the advice from GOOS: Listen to your tests.
언제나 그렇듯이, 우리는 GOOS의 충고를 명심해야 한다: 당신의 테스트에 귀를 기울이세요.
If you think that it's ridiculous to write tests for automatic properties, then what is the feedback really about?
만약 당신이 자동 프로퍼티를 위한 테스트를 작성하는 것이 터무니없다고 생각한다면, 그 피드백은 정말 무엇에 관한 것인가?
Most of my critics present the choices like this: Pick one of the boxes.
대부분의 비평가들은 다음과 같은 선택을 제시합니다. 이 중에 하나의 박스를 선택하라고요.
| Unit test | No unit test | |
| Property |
However, I think the choice is more like this:
하지만 제가 생각하기에 선택은 보다 이와 같습니다.
| Unit test | No unit test | |
| Property | ||
| No property |
If you think that testing a property doesn't provide any value, then listen to the test: Does it even have to be a property? Couldn't a public field be equally good?
프로퍼티를 테스트하는 것이 아무런 가치를 제공하지 않는다고 생각하는 경우 테스트에 귀를 기울입니다. 그것은 프로퍼티이어야만 하나요? public field도 똑같이 좋을 수 있지 않을까요?
In his post on the Pragmatics of TDD, Robert C. Martin states that getters and setters (properties) will be indirectly covered by other tests. This would also be true for public fields. This is even more pronounced in C# where the syntax for accessing a property is identical to the syntax for accessing a field.
TDD의 실용주의에 대한 그의 글에서, 로버트 C. 마틴은 게터와 세터(프로퍼티들)는 다른 테스트에서 간접적으로 다뤄질 것이라고 말합니다. 이것은 공공 분야에서도 마찬가지일 것입니다. 이것은 프로퍼티에 접근하기 위한 구문이 필드에 접근하기 위한 구문과 동일한 C#에서 더욱 두드러집니다.
I agree with both Robert C. Martin and Mark Rendle that in a lot of cases, we don't really care about anything as nitty-gritty as a single property. What we often care about is the overall behavior of a system. This is also the approach I teach in my Pluralsight course on Outside-In Test Driven Development. You don't see me write tests of properties there.
나는 로버트와 마크 렌들 모두에게 동의합니다. 많은 경우에, 우리는 단일 프로퍼티만큼 본질적인 것에 대해 정말로 신경 쓰지 않습니다. 우리가 종종 관심을 갖는 것은 시스템의 전반적인 행동이죠. 이는 외부 테스트 주도 개발에 대한 복수의 시각 교육 과정에서 가르치는 접근 방식이기도 합니다. 여러분들은 내가 거기서 프로퍼티 테스트를 쓰는 것을 볼 수 없습니다.
However, I made a mistake in that course, and another mistake in my previous post, and that was to design View Models with properties. Why are we even adding properties to View Models? The purpose of a View Model is to render in a particular way, either as UI, XML, JSON or something else. We care about the end result, not what the View Model class looks like. At the boundaries, applications aren't object-oriented.
하지만 저는 그 과정에서 실수를 했고, 이전 게시물에서 또 다른 실수를 했습니다. 그것은 속성을 가진 View Models를 설계하는 것이었습니다. View Model에 프로퍼티를 추가하는 이유는 무엇입니까? 뷰 모델의 목적은 UI, XML, JSON 또는 다른 것으로 특정한 방식으로 렌더링하는 것입니다. View Model 클래스가 아니라 최종 결과를 고려합니다. 경계에서 응용프로그램은 객체 지향적이지 않습니다.
The JournalEntryModel from my Pluralsight course should really have look like this:
public class JournalEntryModel
{
public DateTimeOffset Time;
public int Distance;
public TimeSpan Duration;
}
Notice that the class simply holds three public fields. This produces the same JSON as the version where those three members are properties.
클래스에는 세 개의 공용 필드가 있습니다. 이렇게 하면 세 member가 프로퍼티인 버전과 동일한 JSON이 생성됩니다.
Summary
There may still be cases where properties are appropriate. If, for example, instead of writing an end-to-end application, you are writing a reusable library, properties provide encapsulation. In such cases, the property has a particular purpose, and it still makes sense to me to capture that behavior (yes: behavior, not data) in a regression test.
여전히 프로퍼티들이 적절한 경우가 있을 수 있습니다. 예를 들어, 엔드 투 엔드 응용프로그램을 작성하는 대신 재사용 가능한 라이브러리를 작성하는 경우 프로퍼티는 캡슐화를 제공합니다. 이러한 경우 프로퍼티는 특정 목적을 가지고 있으며 회귀 검정에서 해당 동작(예: 데이터가 아닌 동작)을 캡처하는 것이 여전히 타당합니다.
However, most of the times properties aren't warranted, and you might as well use a public field - this is the YAGNI principle applied. You don't have to test public fields because they can't possibly have any behavior.
그러나 대부분의 경우 프로퍼티들은 보증되지 않으며 공용 필드를 사용하는 것이 좋습니다. 이것이 YAGNI 원칙입니다. 공용 필드는 어떤 행동도 할 수 없기 때문에 테스트할 필요가 없습니다.