테스트 주도 개발이 대체 뭐야?!
                                            
                                                
                                                
                                                
                                                
                                                
                                                 7187 단어  webdevreacttestingjavascript
                    
"이봐, 하지만 마감일을 맞추고 작동하는 실제 코드를 작성하는 데 더 느려지지 않을까?"
그것을 연습할 시기를 결정하는 것이 실제 작업입니다. 이러한 테스트를 작성하는 동안 약간의 시간이 소요될 수 있습니다. 당신은 이상하고 가장 예상치 못한 방법으로 당신의 코드를 더 잘 알 수 있을 것입니다. 그리고 저를 믿으세요. 당신의 코드에 대한 테스트를 작성하는 것은 재미있습니다. (테스트를 테스트하기 위해 테스트용 테스트를 작성하지 않기 때문에 테스트 자체에 버그가 있을 때까지)

어쨌든! 제가 여기서 말하고자 하는 것은 이 관행은 생명의 은인이 되는 것과 완전히 시간을 낭비하는 것의 매우 미세한 차이가 있다는 것입니다.
원칙
테스트 주도 개발의 패러다임은 다음과 같이 말합니다.
One should write a failing test, write some code to pass the test, and then write some more tests continuously refactoring the code alongside

이 철학은 제품 요구 사항이 안정적이지 않고 자주 변경되는 경우와 같이 구현하기에 항상 실용적인 것은 아닙니다. 그러나 매우 명확한 요구 사항이 있는 상황에 이상적이며 생산성, 코드 신뢰성 및 정신 건강을 크게 향상시킵니다.
"좋은 것 같지만 테스트를 어떻게 작성할 수 있습니까?"
손을 더럽히기 전에 몇 가지 일반적인 유형의 테스트를 살펴보겠습니다.
단위 테스트
단위 테스트는 개별 기능에 대한 작성 테스트를 단위 테스트라고 할 수 있는 것처럼 소프트웨어 단위의 기능을 확인하기 위해 작성된 테스트입니다. 함수가 반환하는 내용과 주어진 입력 세트와 상호 작용하는 방식을 확인합니다.
통합 테스트
통합 테스트는 결과를 집합적으로 생성하기 위해 서로 호출 및 참조하는 여러 소프트웨어 단위의 상호 작용을 확인/테스트하기 위해 작성되었습니다.

종단 간 테스트
시중에는 실제 사용자 행동을 에뮬레이션하기 위해 ** 시뮬레이션된 환경에서 앱을 실행하는 ** 개별 및 집단 코드 블록의 오케스트레이션을 확인하는 많은 자동화 도구가 있습니다. cypress은 다른 종단 간 테스터 사이에서 인기 있는 선택입니다.
첫 번째 테스트를 작성하여 TDD를 시작하겠습니다.
설정
여기 React 앱이 있습니다. 일부 불필요한 파일을 지운 후 파일 구조는 다음과 같습니다. (네 CSS파일 불필요하게 분류해서 지웠는데 저를 뭐라고 부를까요? 스타일리스트?!)
 
CRA(create-react-app) 템플릿에는 본격적인 웹 앱을 테스트하는 데 필수적인 종속성을 포함하는 상용구 코드가 이미 포함되어 있습니다.
React를 사용하여 독립 웹 앱에서 이러한 라이브러리를 얻으려면 문서here를 확인하십시오. (문서는 항상 옳습니다!)
 
이제 모든 설정이 완료되었으므로 앱을 빌드해 보겠습니다.
 암호
이제 우리의 동기는 빠르고, 신뢰할 수 있고, 효율적이고, 성능이 뛰어나고, 인체 공학적이고, 경제적이며, 황홀하고, 창의적인 카운터 앱을 구축하는 것입니다. TDD의 원칙에 따르면 실패한 테스트를 작성한 다음 테스트를 통과할 실제 코드를 작성해야 합니다.
이 테스트를 살펴보겠습니다.
 import { render, screen } from '@testing-library/react'
import App from './App'
test('Give some name to this test in order to see it written in red', () => {
    let counterCheck = 0
    render(<App />)
    // get the add button used to add counter
    const addButton = screen.getByText(/Add/)
    for (let i = 0; i < 3; i++) {
        // click the add button to increase the value of the counter
        addButton.click()
        // increment the value of our check alongside to compare counter and our check
        counterCheck += 1
    }
    // All operations on our element done lets now fetch and check the value of our element
    let linkElement = screen.getByText(/Counter Value: .+/)
    expect(linkElement.innerHTML === 'Counter Value: ' + String(counterCheck)).toBeTruthy()
})
npm run test로 위의 테스트를 실행하면 아직 요소를 정의하지 않았기 때문에 실패합니다. 이제 카운터 앱을 만들어 보겠습니다.
 
이제 테스트를 다시 실행해 보겠습니다...
 
  
                
                    
        
    
    
    
    
    
                
                
                
                
                    
                        
                            
                            
                            Reference
                            
                            이 문제에 관하여(테스트 주도 개발이 대체 뭐야?!), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
                                
                                https://dev.to/kuvambhardwaj/what-the-heck-is-test-driven-development-anyway--4loe
                            
                            
                            
                                텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
                            
                            
                                
                                
                                 우수한 개발자 콘텐츠 발견에 전념
                                (Collection and Share based on the CC Protocol.)
                                
                                
                                우수한 개발자 콘텐츠 발견에 전념
                                (Collection and Share based on the CC Protocol.)
                            
                            
                        
                    
                
                
                
            
이제 우리의 동기는 빠르고, 신뢰할 수 있고, 효율적이고, 성능이 뛰어나고, 인체 공학적이고, 경제적이며, 황홀하고, 창의적인 카운터 앱을 구축하는 것입니다. TDD의 원칙에 따르면 실패한 테스트를 작성한 다음 테스트를 통과할 실제 코드를 작성해야 합니다.
이 테스트를 살펴보겠습니다.
import { render, screen } from '@testing-library/react'
import App from './App'
test('Give some name to this test in order to see it written in red', () => {
    let counterCheck = 0
    render(<App />)
    // get the add button used to add counter
    const addButton = screen.getByText(/Add/)
    for (let i = 0; i < 3; i++) {
        // click the add button to increase the value of the counter
        addButton.click()
        // increment the value of our check alongside to compare counter and our check
        counterCheck += 1
    }
    // All operations on our element done lets now fetch and check the value of our element
    let linkElement = screen.getByText(/Counter Value: .+/)
    expect(linkElement.innerHTML === 'Counter Value: ' + String(counterCheck)).toBeTruthy()
})
npm run test로 위의 테스트를 실행하면 아직 요소를 정의하지 않았기 때문에 실패합니다. 이제 카운터 앱을 만들어 보겠습니다.
이제 테스트를 다시 실행해 보겠습니다...

 
                Reference
이 문제에 관하여(테스트 주도 개발이 대체 뭐야?!), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/kuvambhardwaj/what-the-heck-is-test-driven-development-anyway--4loe텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
                                
                                
                                
                                
                                
                                우수한 개발자 콘텐츠 발견에 전념
                                (Collection and Share based on the CC Protocol.)