단위 테스트 이론(계속): 2부

지난 기사에서는 WordPress의 단위 테스트 이론에 대해 논의하기 시작했습니다. 특히 단위 테스트 테마 및 플러그인에 대한 작업을 검토한 다음 코드 단위에 대해 논의하고 이것이 테스트에 어떤 영향을 미치는지 논의하며 더 넓은 소프트웨어 개발 세계에서 단위 테스트를 검토합니다.

WordPress의 단위 테스트 이론에 대해 계속해서 논의할 예정이지만 문제 식별, 아키텍처 구동, 문서 프로젝트 등에 어떻게 도움이 될 수 있는지에 대한 관점에서 논의하겠습니다.

문제를 찾아 시간을 절약하세요

이 시리즈의 앞부분에서 단위 테스트에 대한 전통적인 접근 방식은 다음과 같습니다.

• 테스트를 작성하고 실행하세요(실패할 것임을 알고 있음)
• 이 메서드를 통과시키는 함수를 작성하세요.
• 테스트를 실행해 보세요. 테스트가 실패하면 해당 기능에 대한 작업을 계속하세요. 그렇지 않으면 다음 단계로 이동하세요.

예, 첫 번째 단계는 약간 독단적입니다. 실패할 것임을 알면서도 왜 실행에 시간을 낭비합니까? 그러나 당신은 요점을 이해합니다. 그러나 이 특정 기술을 개발에 적용하기 시작하면 코드를 작성할 때 특정 리듬이 개발된다는 것을 알게 될 것이며 이것이 전체 목표의 일부입니다.

하지만 그것은 절반에 불과합니다. 단위 테스트는 실제로 개발 초기에 문제를 파악하는 데 도움이 될 수 있습니다.

이를 이해하려면 이 아이디어를 검토하는 것이 가장 좋습니다.

사용자가 실제로 WordPress 대시보드에 로그인하지 않고도 사용자 계정을 생성할 수 있도록 하는 WordPress 기반 프로젝트용 기능을 개발 중이라고 가정해 보겠습니다. 이는 등록, 필요한 확인, 비밀번호 및 이메일 생성을 위한 코드를 처리하기 위한 페이지 템플릿을 설정했다고 가정합니다.

브라우저에 페이지를 로드하고 일부 사용자를 생성하려고 합니다. 일부는 동일한 이메일 주소를 사용하고 일부는 잘못된 비밀번호를 사용하고 일부는 불법 문자를 사용하는 등의 작업을 수행합니다. 아이디어를 얻었습니다. 통과 및 실패를 확인하는 방법에는 여러 가지가 있습니다. 이건 너무 거칠다! 즉, 사용자 등록 기능을 변경할 때마다 동일한 n번의 등록을 수행해야 문제가 발생하지 않는다는 것을 의미합니다.

또는 이를 처리하고 코드가 변경될 때마다 실행할 테스트 세트를 작성할 수도 있습니다.

그렇습니다. 단위 테스트를 작성하는 데는 많은 시간이 걸릴 수 있지만, 코드 단위를 수정할 때마다 절약되는 시간을 살펴보세요. 이는 그만한 가치가 있으며 누군가가 테스트의 한 순열을 모의하는 것을 잊어버렸기 때문에 놓쳤을 수 있는 문제를 조기에(즉, 프로덕션으로 출시하기 전에) 파악하는 데 도움이 될 수 있습니다.

자체 녹음

단위 테스트를 작성할 때 코드가 실제로 작동하는지 확인하여 코드 품질을 향상시킬 뿐만 아니라 기본적으로 개발자용 문서도 제공합니다.

제품에 내장된 기능을 단위 테스트하는 경우 기능이 작동하는 방식, 실패해야 하는 시기, 통과해야 하는 경우에 대한 문서를 제공합니다.

여기에는 몇 가지 가정이 있습니다. 특히 함수 및 관련 테스트의 이름을 논리적으로 지정하고 그룹화하며 각 함수를 올바르게 테스트하고 있습니다.

PHPUnit을 사용하면 WordPress 단위 테스트에서 읽기 쉬운 어설션을 쉽게 실행할 수 있습니다. 프로젝트를 구성하는 함수에서 사용할 수 있는 AssertTrue, AssertFalse 또는 기타 어설션을 선언하기만 하면 됩니다.

위의 예에 따르면 이는 빈 이메일 주소로 등록하려고 할 때 사용자 등록 기능이 실패하도록 보장하는 함수를 작성할 수 있음을 의미합니다.

간단한 예일 수도 있지만 요점은 남아 있습니다. 코드는 자체 문서화되며 명확한 단위 테스트만 작성하면 됩니다.

건축

단위 테스트의 가장 과소평가된 장점 중 하나는 프로젝트 아키텍처를 추진하는 데 도움이 될 수 있다는 것입니다. 일반적으로 테마 또는 플러그인 개발은 다음 두 가지 방법 중 하나로 시작할 수 있습니다.

1. 함수 나열, UI 그리기, 코드 작성
2. 파일이 함께 작동하는 방식에 대한 다이어그램을 그린 다음 코드를 작성하세요

이것들은 본질적으로 나쁜 것은 아니지만 약하다고 생각합니다(내가 공유하고 싶은 것보다 더 많은 일을 한다는 것을 가장 먼저 인정하겠습니다!). 하지만 "코드 작성" 단계에는 많은 책임이 따릅니다. 그렇지 않나요?

오랫동안 코딩을 해온 사람이라면 누구나 “아…

운이 좋다면 이는 일반적으로 무시한 사례를 처리하기 위해 도우미 메서드나 다른 조건문을 작성할 수 있음을 의미하지만, 최악의 경우 이 문제를 해결하기 위해 전체 클래스 또는 전체 컬렉션 함수를 다시 디자인해야 할 수도 있음을 의미합니다. .

단위 테스트는 완벽하지는 않지만 이러한 상황을 완화하는 데 도움이 될 수 있습니다.

처음부터 테마나 플러그인이 제공하기를 원하는 모든 기능의 목록이 있다는 사실을 생각해 보세요. 아직 코드를 작성하지 않았지만 UI 스케치 및/또는 클래스 다이어그램 세트가 있을 수 있습니다.

接下来，您开始编写要编写的测试以测试您的项目。回想一下，单元测试的一部分是将代码分解为尽可能的原子单元，因此您的任务是为每个单元编写单元测试，咳咳。

由于单元测试的性质，您本质上会以不同的方式思考您的代码：您正在考虑“编写测试”，而不是“编写代码”，并且因为您必须在更原子的级别上进行思考，您会情不自禁地考虑经常被归入“编写代码”的边缘案例。

代码的语言

作为开发人员，我们非常习惯使用不断强化我们编写代码的约定。我的意思是，我们倾向于提供缩写的变量名称、神秘的函数名称和类名称，这些名称对于您自己或项目团队之外的任何人来说可能没有任何意义。

单元测试不一定是编写更易于阅读的代码的关键，但它可以进一步帮助提供更清晰的函数名称。

回想一下您读过的第一本编程书、您参加的第一堂计算机科学课或者您看到的第一段开源代码，方法名称通常是动词。为什么他们不应该这样？方法是封装代码的方法，做一些事情。但随着我们在项目上工作的时间越来越长，我们变得越来越懒，我们的代码从“register_user_and_email_password()”变成“new_account()”。

显然，前者比后者更清晰，但如果我们致力于高质量的单元测试，并且希望确保我们的单元测试易于阅读，为了使它们易于阅读，我们的函数名称必须易于阅读。

这不是更容易阅读吗：

$this->assertFalse( register_user_and_email_password( '' ) );

而不是这个？

$this->assertFalse( new_account( '' ) );

同样，这也许是一个简单的示例，但原则仍然是：编写良好的单元测试，以帮助自我记录驱动函数语言的代码。

结论

我们已经讨论了单元测试的基础知识以及主要优点，但是我们还没有讨论单元测试带来的缺点，我们甚至还没有考虑如何将其合并到我们的项目中。工作流程。

因此，在下一篇文章中，我们将尝试做到这一点。