주니어 과정을 마친 후에도 가끔 도움말 섹션에 와서 뭔가 제안하고 도움을 줍니다. 거의 항상 질문은 "나는 모든 것을 올바르게 했지만 검증자가 나를 들여보내지 않을 것입니다" 또는 이와 유사한 문구로 시작됩니다. 제가 여기에 글을 쓰게 된 것은 바로 이 헤드라인들이었습니다. 이제부터 나는 그것을 진실로 받아들일 것을 제안합니다. 검증자는 항상 옳습니다. 버그가 나타나는 경우도 있지만 매번 그 수가 점점 줄어들고 있습니다. 따라서 검증인으로부터 거부를 받았다면 어딘가에서 실수를 했다고 가정하는 것이 좋습니다. 이제 벽에 머리를 부딪히지 않으려면 마스터링 테스트를 시작해야 합니다. 이 주제에 대한 여러 기사가 있습니다( JUnit 파트 I JUnit 파트 II ). 더욱이 테스트해야 할 것은 "편리한 경우"가 아닙니다. 예를 들어 task1916 작업을 살펴보겠습니다 . 솔루션을 작성한 후 사람들은 이상적인 옵션을 확인하는 경우가 많습니다. 이상적인 옵션이 통과되었습니다. 이는 작업을 제출할 수 있음을 의미합니다. 그리고 거절이 도착합니다. 그렇다면 무엇을 해야 합니까? 맞습니다, 또 다른 테스트 예제를 작성해 보세요. 그런 다음 유효성 검사기가 테스트를 통과할 때까지 계속해서 또 다른 작업을 수행합니다. 예를 들어, 코드는 빈 두 번째 파일에 어떻게 응답합니까? 비어있는 첫 번째 것은 어떻습니까? 최신 예제는 다음과 같습니다 https://javarush.com/help/15861 이제 개발자는 코드를 작성할 뿐만 아니라 테스터에게 의존하지 않고 직접 테스트해야 한다는 점을 이해하는 것이 중요합니다. 솔직히 말해서 개발이 테스트 단계로 접어들면 아직도 조금 겁이 납니다. 나는 내 코드가 제대로 작동하고 오류가 없어야 한다고 믿습니다. 작동하지 않는 코드를 공개하면 항상 기분이 좋지 않습니다. 내가 뭔가를 썼는데 확인하지 않은 것으로 밝혀졌습니다. 누군가의 시간을 낭비했습니다. 물론 나중에 직장에서 요구 사항 목록을 갖게 될 것이며 테스터로부터 소프트웨어에 대한 테스트 사례 세트를 가져와 이에 적응할 수 있으며 더 쉬울 것이지만 나는 그것에 의존하지 않을 것입니다. 귀하의 코드는 귀하의 책임이며, 테스트는 모든 것이 제대로 작동하는지 확인하는 데 도움이 됩니다. 이제 테스터 기술을 향상시킬 수 있는 좋은 기회가 생겼습니다. 도움말 섹션에 들어갈 때 작성자에게 코드 형식으로 답변을 작성하지 마십시오. 그에게 적합하지 않은 테스트 예제를 생각해 보세요. 이렇게 하면 작성자를 위해 문제를 해결하지 않고도 자신을 향상시키고 작성자를 도울 수 있습니다.
GO TO FULL VERSION