언제/얼마나 자주 테스트해야 합니까?

Question

첫 번째 전문 프로젝트의 리듬에 적응하고 있는 초보 개발자로서, 가능한 한 빨리 좋은 습관을 기르려고 노력하고 있습니다.그러나 나는 종종 테스트하는 것을 잊어버리거나, 미루거나, 한 번에 하나씩 수행하는 대신 빌드가 끝날 때 전체 테스트를 수행하는 것을 발견했습니다.

내 질문은 대규모 프로젝트를 작업할 때 어떤 리듬을 선호하는지, 그리고 테스트가 어디에 적합한지입니다.

Answer 1

음, TDD 사람들을 따르고 싶다면, 코딩을 시작하기 전에 ;)

나는 당신과 매우 같은 입장입니다.나는 더 많은 테스트를 하고 싶지만 현재는 "코드를 올바르게 가져오는 것"보다는 "코드를 꺼내는" 작업을 하고 있는 위치에 있습니다. 그래서 겁이 납니다.그래서 저는 천천히 개발 주기에 테스트 프로세스를 통합하려고 노력하고 있습니다.

현재, 나는 코드를 작성하면서 테스트하고, 코드를 작성하면서 코드를 파괴하려고 노력합니다..TDD 사고방식을 받아들이는 것이 어렵다는 것을 알았습니다.시간은 걸리지만 나는 그렇게 할 거야 원하다 일하다..

편집하다:

나는 이것을 확장해야 한다고 생각했습니다. 이것이 나의 기본 "작업 프로세스"입니다...

1. 코드에서 원하는 것을 계획, 가능한 객체 설계 등 무엇이든 계획하십시오.
2. 내 첫 번째 수업을 만들고, 수업에 대한 나의 "비전"이 무엇인지 설명하는 상단에 큰 의견을 추가하십시오.
3. 기본 테스트 시나리오 개요이것들은 기본적으로 단위 테스트가됩니다.
4. 첫 번째 방법을 만듭니다..또한 그것이 어떻게되는지 설명하는 짧은 의견을 작성합니다 예상되는 일하다.
5. 내가 기대하는 대로 작동하는지 확인하기 위해 자동화된 테스트를 작성합니다.
6. 각 방법에 대해 4~6단계를 반복합니다. 자동화된 테스트는 F5에서 실행되는 거대한 목록에 있습니다.
7. 그런 다음 작업 환경에서 클래스를 에뮬레이션하기 위해 몇 가지 강력한 테스트를 만들어 모든 문제를 확실히 해결합니다.
8. 이후에 새로운 버그가 발견되면 돌아가서 새 테스트를 작성하고 실패했는지 확인한 다음(이는 버그에 대한 개념 증명 역할도 함) 수정합니다.

도움이 되었기를 바랍니다..이것이 내 관심사라고 말했듯이 이 문제를 개선하는 방법에 대한 의견을 여십시오.

Answer 2

코드를 체크인하기 전에

Answer 3

처음이자 자주.시스템에 대한 몇 가지 새로운 기능을 만드는 경우 처음에는 인터페이스를 정의한 다음 해당 인터페이스에 대한 단위 테스트를 작성하려고 합니다.인터페이스의 API와 인터페이스가 제공하는 기능을 고려하여 작성할 테스트를 결정하려면 펜과 종이를 꺼내 잠재적인 오류 조건이나 올바른 작업을 수행하고 있음을 증명하는 방법에 대해 잠시 생각해 보십시오.이것이 너무 어렵다면 API가 충분하지 않을 가능성이 높습니다.테스트와 관련하여, 둘 이상의 특정 개체를 테스트하는 "통합" 테스트 작성을 피하고 이를 "단위" 테스트로 유지할 수 있는지 확인하세요.

그런 다음 인터페이스의 기본 구현을 생성하고(아무 작업도 하지 않고 쓰레기 값을 반환하지만 예외를 발생시키지 않음) 이를 테스트에 연결하여 테스트가 실패하는지 확인합니다(이 테스트는 테스트가 작동하는지 확인합니다!:)).그런 다음 기능을 작성하고 테스트를 다시 실행하세요.이 메커니즘은 완벽하지는 않지만 많은 간단한 코딩 실수를 다루고 전체 애플리케이션에 연결하지 않고도 새 기능을 실행할 수 있는 기회를 제공합니다.

그런 다음 기존 기능을 결합하여 기본 애플리케이션에서 테스트해야 합니다.테스트가 더 어려운 곳이며 가능하다면 문제를 깨는 재주가 있는 좋은 QA 테스터에게 부분적으로 아웃소싱해야 합니다.하지만 이러한 기술도 있으면 도움이 됩니다.테스트를 올바르게 수행하는 것은 솔직하게 배워야 할 요령입니다.내 경험은 내 자신의 순진한 배포와 사용자가 분노하여 이를 사용할 때 보고한 후속 버그에서 비롯됩니다.

처음에 이런 일이 일어났을 때 나는 사용자가 의도적으로 내 소프트웨어를 망가뜨리려고 한다는 사실에 짜증이 났고 모든 "버그"를 "교육 문제"로 표시하고 싶었습니다.하지만 곰곰이 생각해 보니 바보라도 사용할 수 있도록 애플리케이션을 최대한 간단하고 안정적으로 만드는 것이 (개발자로서) 우리의 역할이라는 것을 깨달았습니다.바보들에게 권한을 부여하는 것이 우리의 역할이고 그것이 바로 우리가 돈을 받는 이유입니다.바보 취급.

이렇게 효과적으로 테스트하려면 모든 것을 깨뜨리려는 마음가짐을 가져야 합니다.버튼을 강타하고 일반적으로 이상하고 놀라운 방법으로 애플리케이션을 파괴하려고 시도하는 사용자의 역할을 가정해 보십시오.결함을 발견하지 못하면 생산 과정에서 결함이 발견되어 회사의 체면이 크게 손상될 것이라고 가정하십시오.이러한 모든 문제에 대해 전적인 책임을 지고 프로덕션에서 책임이 있는(또는 부분적으로) 버그가 발견되면 자신을 저주하십시오.

위의 대부분을 수행하면 훨씬 더 강력한 코드를 생성하기 시작할 수 있지만 이는 약간의 예술 형식이며 능숙해지려면 많은 경험이 필요합니다.

Answer 4

기억해야 할 좋은 열쇠는

"일찍 테스트하고, 자주 테스트하고, 끝났다고 생각되면 다시 테스트하세요."

Answer 5

언제 테스트하나요?코드가 올바르게 작동하는 것이 중요한 경우!

Answer 6

혼자 뭔가를 해킹할 때는 마지막에 테스트를 해요.나쁜 습관이지만 이것들은 일반적으로 몇 번 사용할 작은 것들이며 그게 전부입니다.

대규모 프로젝트에서는 클래스를 작성하기 전에 테스트를 작성하고 해당 클래스가 변경될 때마다 테스트를 실행합니다.

Answer 7

나는 끊임없이 테스트한다.함수 내부의 루프를 마친 후에는 프로그램을 실행하고 루프 상단의 중단점에 도달한 다음 전체를 실행합니다.이는 프로세스가 내가 원하는 대로 정확히 수행되고 있는지 확인하기 위한 것입니다.

그런 다음 기능이 완료되면 전체를 테스트합니다.함수가 호출되기 직전에 중단점을 설정하고 디버거를 확인하여 완벽하게 작동하는지 확인하는 것이 좋습니다.

나는 이렇게 말할 것 같다:"자주 테스트해 보세요."

Answer 8

최근에야 정규 작업 흐름에 단위 테스트를 추가했지만 단위 테스트를 작성합니다.

• 각각의 새로운 코드 모듈에 대한 요구 사항을 표현하기 위해(인터페이스를 작성한 직후, 구현을 작성하기 전)
• 그럴 때마다 "더 좋았을 텐데..."라고 생각할 때마다내가 끝날 때쯤엔"
• 뭔가 고장이 났을 때, 버그를 정량화하고 그것을 고쳤다는 것을 증명하기 위해
• 명시적으로 메모리를 할당하거나 할당 해제하는 코드를 작성할 때---나는 메모리 누수 찾기를 싫어합니다...

대부분의 빌드에서 테스트를 실행하며 항상 코드를 실행하기 전에 실행합니다.

Answer 9

단위 테스트부터 시작하세요.특히 TDD(Test Driven Development)를 확인해 보세요.TDD의 기본 개념은 단위 테스트를 먼저 작성한 다음 코드를 작성하는 것입니다.테스트가 실패하면 돌아가서 코드를 다시 작업하세요.통과하면 다음 단계로 넘어갑니다.

나는 TDD에 하이브리드 접근 방식을 취합니다.나는 아무것도 아닌 것에 대한 테스트를 작성하는 것을 좋아하지 않기 때문에 일반적으로 일부 코드를 먼저 작성한 다음 단위 테스트를 넣습니다.이는 결코 완료할 수 없는 반복적인 프로세스입니다.코드를 변경하고 테스트를 실행합니다.오류가 있으면 수정하고 반복하세요.

다른 종류의 테스트는 통합 테스트로, 프로세스 후반에 수행되며 일반적으로 QA 테스트 팀에서 수행할 수 있습니다.어떤 경우든 통합 테스트는 전체 부분을 테스트해야 하는 필요성을 해결합니다.테스트와 관련하여 작동하는 제품입니다.이는 일반적으로 자동화된 테스트 도구(예: 로봇)를 사용하는 것과 관련하여 처리하기가 더 어렵습니다.

또한 연속 빌드를 수행하려면 CruiseControl.NET과 같은 제품을 살펴보세요.CC.NET은 각 빌드마다 단위 테스트를 실행하여 오류가 발생하면 즉시 알려줍니다.

Answer 10

여기서는 TDD를 수행하지 않지만(일부에서는 이를 옹호함) 규칙은 변경 사항에 따라 단위 테스트를 확인해야 한다는 것입니다.항상 그런 것은 아니지만, 돌아가서 특정 변경 세트를 살펴보고 테스트가 작성되었는지 여부를 확인하는 것은 쉽습니다.

Answer 11

테스트할 새 기능 작성이 끝날 때까지 기다리면 기능이 중단될 수 있다고 생각했던 극단적인 경우를 많이 잊어버리게 됩니다.스스로 배우기 위해 일을 한다면 괜찮지만, 전문적인 환경에서는 내 흐름이 다음과 같은 고전적인 형태라고 생각합니다.빨간색, 녹색, 리팩터링.

빨간색:테스트가 실패하도록 작성하세요.이렇게 하면 테스트가 올바른 변수에 대해 어설션하고 있음을 알 수 있습니다.

녹색:가능한 가장 쉬운 방법으로 새로운 테스트를 통과하세요.하드 코딩을 의미한다면 괜찮습니다.이는 즉시 작동하기를 원하는 사람들에게 적합합니다.

리팩터링:이제 테스트가 통과되었으므로 다시 돌아가 자신 있게 코드를 변경할 수 있습니다.새로운 변경 사항으로 인해 테스트가 중단되었나요?좋습니다. 귀하의 변경 사항에는 귀하가 깨닫지 못한 의미가 있습니다. 이제 테스트를 통해 알 수 있습니다.

이 리듬 덕분에 시간이 지남에 따라 개발 속도가 빨라졌습니다. 기본적으로 기능이 작동하기 위해 확인해야 한다고 생각한 모든 사항에 대한 기록 컴파일러가 있기 때문입니다!이는 결과적으로 여기서 설명할 수 없는 다른 많은 이점으로 이어집니다.

Answer 12

여기에 많은 훌륭한 답변이 있습니다!

나는 이해가 되는 가장 낮은 수준에서 테스트하려고 합니다.

• 단일 계산이나 조건이 어렵거나 복잡한 경우 작성하는 동안 테스트 코드를 추가하고 각 부분이 작동하는지 확인하세요.완료되면 테스트 코드를 주석 처리하되 알고리즘 테스트 방법을 문서화하기 위해 그대로 두십시오.

• 각 기능을 테스트해 보세요.

  • 각 지점을 적어도 한 번 연습하십시오.
  • 운동하다 경계 조건 -- 코드가 동작을 변경하는 입력 값 - "off by one" 오류를 포착합니다.
  • 유효한 입력과 잘못된 입력의 다양한 조합을 테스트합니다.
  • 코드를 깨뜨릴 수 있는 상황을 찾아 테스트하세요.

• 위와 동일한 전략으로 각 모듈을 테스트합니다.

• 코드 본문을 전체적으로 테스트하여 구성 요소가 올바르게 상호 작용하는지 확인하십시오.하위 수준 테스트를 부지런히 수행했다면 이는 본질적으로 조립 중에 파손된 부분이 없는지 확인하는 "신뢰도 테스트"입니다.

내 코드의 대부분은 임베디드 장치용이므로 견고성, 다양한 스레드, 작업 및 구성 요소 간의 상호 작용, 예상치 못한 리소스 사용에 특히 주의를 기울입니다.메모리, CPU, 파일 시스템 공간, 등.

일반적으로 오류가 일찍 발생할수록 오류를 격리, 식별 및 수정하기가 더 쉬워지고 뒤쫓는 것보다 만드는 데 더 많은 시간을 할애할 수 있습니다.*

**알고 있습니다. 불필요한 버퍼 포인터 참조는 -1입니다!*