답변:
법률 영어에 오신 것을 환영합니다.
"should"== "shall"== 계약 의무 사용. 법입니다. "질문"으로 이어지지 않습니다. 문장을 공식 계약 의무로 표시합니다.
"would"== "will"== 좋은 아이디어를 사용하는 것. 문장을 선택적 기능으로 표시합니다.
질문은 촉진, 조직, 도움, 신뢰 구축의 일부입니다. 단어 선택의 결과가 아닙니다.
수정 자없이 베어 동사를 사용하면 문장을 공식 요구 사항으로 강조하기가 약간 어려워집니다. 그리고 초 복잡한 동사의 경우, 그것을 활용하는 방법을 알아 내기 위해 약간의 욕설을 얻을 수 있습니다.
쉬움- "알다"또는 "만들다"와 같은 동사.
시스템은 이메일을 통해 알립니다. ( "알림"동사는 "시스템"에 대해 "알림"으로 표현됩니다.
시스템은 이메일을 통해 통지해야합니다. ( "알림"은 "통지해야 함"이됩니다-활용되지 않습니다. 매우 간단합니다.)
단단함- "로그인"과 같은 동사 문구 또는 "추출, 정리, 변환, 중복 제거 및로드"와 같은 도메인 특정 동사 문구 또는 "잠재적"과 같은 명사 몇 개의 동사가 묻혀있는 더 긴 구절은 겹치기 어렵다 : 각 동사를 켤까요? 아니면 긴 단어를 마치 한 단어 인 것처럼 켤까요? 명사를 영어로 동사를 만들 수 있기 때문에, 그 동사들을 어떻게 조합시키는 지 알기가 어렵습니다.
사용자가 Enter를 클릭하면 시스템이 추출, 정리, 변환, 중복 제거 및로드됩니다. (영어는 명사구를 사소하게 사용합니다.) 아니면 추출, 정리, 변형, 중복 제거 및로드입니까?
사용자가 Enter를 클릭하면 시스템이 추출, 정리, 변환, 중복 제거 및로드되어야합니다. (끔찍한 문구는 그대로 사용되며 동사 활용에 대한 신비는 없습니다.)
["뭐?" "명사를 영어로 번역 할 수 있습니까?"라고 말합니다. 예. 명사. 나는 그것에 대해 벽으로 갈거야. 나는 종종 그것에 대해 돌담을했습니다. 사양조차도 그에 대한 벽으로 막아야한다.]
순전히 문체 선호의 문제. 그것은 당신이 현재 또는 미래 시제로 시스템에 대해 생각하는 것을 선호합니까?
"should"또는 "will"과 같은 한정자는 미래 시제를 암시하지만, 현재 시제로 생각할 때 부드럽고 충분히 읽을 수 있습니다. 한정자 부족은 현재 시제를 나타냅니다 (즉, 지금이 순간).
나는 두 가지 경우 모두 잘 읽을 수 있기 때문에 한정자를 사용하는 것을 선호하지만 모든 것이 미래 시제 일 때 개발 중에 한정자가 부족하면 조금 이상하게 읽습니다.
어쨌든 한정자를 사용하기로 결정한 경우 "should"대신 "must"를 사용하는 것이 좋습니다 . "Should"는 선택적인 것으로 해석 될 수 있지만 (S.Lott의 반대 주장에도 불구하고) "필수"는 모호성을 완전히 제거해야합니다. "선택적이 아닌"을 분명히 의미해야합니다.
그리고 아직 (카르마 제약)에 대해서는 언급 할 수 없기 때문에, 이것은 S.Lott에 대한 행동 / 의견 대 의지 / 의사에 대한 답변입니다. 설명은이 기사를 참조하십시오 .
예선전없이 3 인칭 시제 를 사용하는 것을 선호 합니다.
나의 주요 주장은 : 테스트는 이야기입니다.
스토리는 장면으로 구성됩니다. 각 장면은 다음을 설명합니다.
예:
DESCRIBE :
getReceipt기능컨텍스트 : 영수증이 있습니다
IT : 영수증을 반환
좋은 이야기처럼 좋은 테스트는 읽기 쉽습니다.
이야기는 프로그램이 무엇을하는지 알려줍니다.
반면, 한정자를 사용하면 ( "필수"또는 "필수"인 경우 상관 없음) 테스트가 다음과 같이 어설 션 목록으로 바뀝니다.
지속적인 이야기는 없습니다 : 당신의 마음은 주장의 목록을 평가하고 있습니다.
이것은 주관적이지만, 어설 션 목록을 읽는 것보다 자연어 (이야기)를 읽는 것이 더 간단합니다.
제 생각에는 항상 '해야합니다'를 사용해야합니다.
추론-BDD를 사용하면 테스트를 작성할 때 소프트웨어가 원하는 작업을 아직 수행 하지 않으므로 "무언가를한다"고 말하는 것은 거짓입니다. 그것은 "무언가를해야한다"는 것이며, 그 일을 계속 하는 한 테스트는 통과 할 것입니다.
에서 behaviour-driven.org 제목 "GettingTheWordsRight" :
간단히 말해서, 사물을 묘사하기 위해 사용하는 단어는 우리 (및 다른 사람들)가 그 사물에 대해 생각하는 방식에 영향을줍니다. 이것은 의미론에 대해 사소한 것에 대한 단순한 질문이 아닙니다. 특정 단어에는 지적 및 감정적 수준에서 문구의 의미를 해석하는 방법에 영향을 미치는 뉘앙스가 있습니다. 우리의 언어는 설명적인 단어와 문구가 풍부하기 때문에 코드에서 설명하고자하는 요소의 의도를 명확하게 전달하는 단어를 사용하는 것이 합리적입니다.
BDD의 경우 테스트를 명명 할 때 거의 항상 단어를 사용하는 사람은 개인적 으로 사용됩니다. 사용법은 테스트가 특정 결과를 제공하기위한 의도이지만 다른 예기치 않은 결과 가 발생할 수 있음을 의미하기 때문에 처리해야합니다. 테스트 결과가 유효한 것으로 간주되는 경우. 당신은 아마 기대 하거나 해야 할 단어를 사용할 수 있습니다유사하게,이 단어들은 테스트의 이름이 "테스트에 아무 문제가없고 구현이 엉망이라고 가정한다"라는 의미로 오해 할 수있는보다 명령적인 관점을 암시한다. 반면 * *는 테스트가 테스트 결과가 더 이상 나타나지 않는 경우 오류가 없는지 다시 확인해야 할 수도 있습니다. 이것이 마음에 들었습니다. 코딩 할 때 열린 마음을 유지하도록 격려하는 생각에 영향을 미치기 때문입니다. 코드를 디버깅하려고 시도하고 가정으로 인해 잘못된 위치에서 오류를 찾는 것을 막을 때 방해받지 않으려는 경우 중요합니다.
그러나 나는 단어 의 접두사로 시행되었을 때 단어의 거의 '종교적인'적용 이 실패 해야한다는 것을 보았습니다. 의미가 있었고, 그러한 경우 에는 단어를 올바르게 작성 하려는 의도가 기대에 미치지 못하고 결과적으로 테스트 자체를 해독하기가 어려워졌습니다. 상황이 이런 종류가 작물 때, 나는 보통 단어를 사용하는 것이 해야테스트 방법 이름 내의 어느 곳에서나 이름이 방법을 간단하고 명확하게 전달하도록합니다. 그러나 특정 문맥 내에서 다른 단어가 똑같이 적절하다면 특정 단어 사용을 강제하지는 않을 것입니다. 그러나 요령은 코드에서 무엇을 나타내는 지에 대한 논쟁의 여지가없는 단어를 선택하고, 단순한 의미에 의존하지 않고 코드가해야 할 일에 대해 생각하도록 자극하는 단어를 선택하는 것입니다.