तीन-चरण पैटर्न के साथ बेहतर परीक्षण लिखें

(यह अभ्यास रेल से एक छोटा अंश है। पहला अध्याय मुफ्त पाने के लिए यहां साइन अप करें!)

तो, आप एक नए ऐप पर काम कर रहे हैं, और रेल ने अभी आपके लिए एक परीक्षण तैयार किया है:

require 'test_helper'

class BugTest < ActiveSupport::TestCase
  # test "the truth" do
  #   assert true
  # end
end

आप इसे अनसुना करते हैं, एक नाम के साथ आते हैं, और आप अपना परीक्षण लिखने के लिए तैयार हैं, है ना? लेकिन फिर क्या? आप पहले क्या लिखते हैं? आपका परीक्षण कोड कैसा दिखना चाहिए?

यदि आप एक सरल पैटर्न का पालन करते हैं, तो आप कोड की उन ठूंठदार पंक्तियों को स्पष्ट, अच्छी तरह से संरचित परीक्षण मामलों में बदल देंगे।

तीन-चरण परीक्षण पैटर्न

आपके परीक्षण मामलों को तीन चरणों में काम करना चाहिए:

1. सबसे पहले, आप कुछ सामान सेट करें ("व्यवस्थित करें")
2. फिर, आप कुछ करते हैं ("अधिनियम")
3. फिर, आप सुनिश्चित करते हैं कि आप जो होने की उम्मीद कर रहे थे, वह वास्तव में हुआ। ("जोर")

उदाहरण के लिए, कल्पना करें कि आप रूबी में एक सरणी पर एक विधि का परीक्षण कर रहे थे। इस पैटर्न का अनुसरण करते हुए, आपका परीक्षण ऐसा दिखाई दे सकता है:

test "Array#sort will sort an array of numbers" do
  # arrange
  unsorted_array = [7, 4, 2, 3]
  
  # act
  sorted_array = unsorted_array.sort

  # assert
  assert_equal [2, 3, 4, 7], sorted_array
end

काफी सरल। लेकिन परीक्षण के प्रत्येक भाग में एक जगह होती है, और परीक्षण का प्रत्येक चरण आपको लगभग बताता है कि इसे कैसे लिखना है।

कभी-कभी, आपको एक व्यवस्थित चरण की आवश्यकता नहीं होगी, या अधिनियम और मुखर चरण संयुक्त हो जाएंगे। लेकिन जब आप अपने परीक्षण लिखते हैं तब भी यह तीनों चरणों के बारे में सोचने में मदद करता है।

द एसर्ट फेज़ गोचा

Assert चरण के लिए एक तरकीब है:आपको उसी तर्क का उपयोग नहीं करना चाहिए जो Act चरण में Assert चरण में उपयोग किया गया था। आपको हमेशा एक ही उत्तर के लिए दो रास्ते अपनाने चाहिए। अन्यथा, आप जिस कोड को कॉल कर रहे हैं, उसमें आपको बग नहीं दिखाई देंगे, क्योंकि इसे अभी Assert चरण में फिर से कॉल किया जा रहा है।

उदाहरण के लिए, यदि आप कुछ गणित कर रहे हैं:

test "average returns the average of a set of numbers" do
  # arrange
  numbers = [1, 2, 3, 4]
  
  # act
  average = numbers.average

  # assert
  
  # this is bad
  assert_equal [1, 2, 3, 4].average, average

  # this is better
  assert_equal 2.5, average
end

कॉलिंग [1, 2, 3, 4].average फिर से मुखर चरण में खराब है, क्योंकि average लगभग कुछ भी लौटा सकता है और वह दावा अभी भी पारित होगा।

यहाँ, यह बहुत स्पष्ट है। लेकिन जब चीजें अधिक जटिल हो जाती हैं, तब भी सुनिश्चित करें कि आप एक ही कोड को केवल दो बार नहीं चला रहे हैं। अन्यथा आप केवल यह सत्यापित कर रहे हैं कि आपकी विधि को कहा जाता था , ऐसा नहीं है कि इसने आपकी अपेक्षा के अनुरूप काम किया।

आमतौर पर, उत्तर के लिए दूसरा रास्ता अपनाने का सबसे आसान तरीका हाथ से उत्तर ढूंढना और उसे हार्डकोड करना है। यह भंगुर हो सकता है, लेकिन यह आपके परीक्षण से बेहतर है कि आप इसे महसूस किए बिना टूट जाएं।

तीन चरण क्यों?

यदि आप अपने परीक्षणों को उन तीन चरणों में विभाजित करते हैं, तो आपके पास उत्तर देने के लिए सरल प्रश्न हैं। "मुझे यह परीक्षा कैसे लिखनी चाहिए?" के बजाय, आप प्रत्येक चरण पर ध्यान केंद्रित कर सकते हैं:"मुझे यह परीक्षण कैसे सेट अप करना चाहिए?", "मैं क्या परीक्षण कर रहा हूं?", "उत्तर कैसा दिखना चाहिए?"

हो सकता है कि इन सवालों के जवाब अभी भी आसान न हों, लेकिन एक बार में पूरी परीक्षा के बारे में सोचने की तुलना में उत्तर बहुत आसान होंगे। और यदि आप भाग्यशाली हैं, तो आप संबंधित परीक्षणों के बीच चरणों को साझा भी कर सकते हैं, जिससे आपका अगला परीक्षण लिखने में बहुत कम दर्दनाक हो जाएगा।