2010-06-26 4 views
5

Euler 프로젝트의 질문을 시작하고 TDD 스타일로 접근하고 싶습니다.하지만 질문에 대한 답을 찾는 데 어려움을 겪고 있습니다. 코드를 포함하지 마십시오. 해당 데이터가있는 리소스가있어 문제를 올바르게 해결했는지 알려주는 테스트 사례를 만들 수 있습니까?Euler 프로젝트 단위 테스트하기

내 동기는 알고리즘이 대답이 아니라 숫자라는 느낌입니다. 다른 사람의 코드 샘플을 보면의 문제를 해결하기 위해 을 알아내는 것이 어려워집니다.

편집 : 다음과 같은 작업을 수행 할 수 있도록 컨텍스트 또는 알고리즘이없는 응답의 번호를 구체적으로 찾고 있습니다. 좀 더 자세한 정보를 알고 있지만 알고리즘을 올바르게 적용했는지 여부를 알기 위해 다른 알고리즘 코드 예제를 보는 것이 아니라 내 알고리즘이 올바른지 여부를 알려주는 합격/불합격 결과를 얻고 싶습니다.

import unittest 
class ProblemOneTest(unittest.TestCase): 
    def test_me(self): 
     self.assertEquals(solve_problem_one(),233168) 

if __name__ == '__main__': 
    print "Problem 1 possible answer: %d" % solve_problem_one() 
    sys.exit(unittest.main()) 
+0

답변을 받으면 도전 과제가 망가질 수 있습니다. 당신이 할 수있는 것은 여러 "솔루션"을 실행하고 그들의 결과를 비교하는 것입니다. –

+2

나를 위해 나는 그 반대를 느낀다. 그 수는 알고리즘이 없으면 무의미합니다. 코드 자체가 답 인 것처럼 느껴져 다른 누군가가 그것을 어떻게 해결했는지 보았습니다. 문제를 해결하는 방법을 알아내는 문제가있었습니다. – Daenyth

+3

컨텍스트 페이지에 번호를 입력하지 않고 "해결했습니다!" 화면이 충분합니까? 단위 테스트가 어떤 도움을 줄 수 있는지 실제로 알지 못합니다. 대신 다른 알고리즘을 작성하고 수정하여 수정하거나 더 빠르게 렌더링하십시오. – nico

답변

4

프로젝트 오일러 웹 사이트의 문제 페이지에 답변을 확인할 수있는 정보가 있습니다. 그게 내가 정말로 필요한 전부 야. 이러한 문제는 방향으로 조종 할 수있는 대답하지 않고 도전을 더 있다는 사실에도 불구하고

11

TDD와 프로젝트 오일러 할당이 반드시 잘 어울리지는 않습니다. 무엇보다도 TDD는 프로젝트 오일러 (PE) 문제를 해결하는 데 도움이되지 않습니다. 이것은 사람이 "스도쿠를 푸는"시도가 잘 알려진 시도 인 것을 상기시켜줍니다. using TDD.

TDD는 설계 기술이 아닙니다. 적용 할 때 매우 유용 할 수 있지만 은색으로 생각하지 마십시오.

PE 문제는 보통 하나의 숫자로 끝나는 무거운 계산을 포함합니다. 이는 대답입니다. TDD를 조심스럽게 적용하려면 PE 문제를 해결하기위한 노력의 일부로 개발할 수학 유틸리티 용으로 TDD를 사용하는 것이 좋습니다. 예를 들어, PE 용 utils 모듈은 소수의 계산, 숫자의 숫자 분할, 문장 검색을위한 함수 등으로 구성됩니다. 이 모듈은 테스트 할 수있을만큼 충분하기 때문에이 모듈은 일반이기 때문에이 모듈에는 일련의 테스트가 있습니다. PE 솔루션 자체에는 테스트가 없습니다. 실제로 필요한 유일한 실제 테스트는 정답을 생성하는 것입니다.

+0

미안 해요, 내가 더 분명하게해야합니다. 나는 그 자체로 문맥이 없기 때문에'assertEquals (my_solution(), expected_answer)'와 같은 것을 할 수있다. 질문을 업데이트하겠습니다. – Daenyth

+0

+1 프로젝트 오일러 문제에 대한 필기 시험은 이미 답변이 있고이를 최적화하려는 경우에만 의미가 있습니다. –

+1

당신은 brute force에 의해 파생 된 값에 대한 한도가 더 작은 문제를 해결하기위한 알고리즘을 테스트 할 수 있습니다. – starblue

1

단위 테스트는 답변입니다.

문제는 대개 너무 간단합니다 (어려움은 없지만 최소한 코드 레이아웃). 여러 가지 방법/클래스로 분류하는 것이 일반적으로 어리석은 문제입니다.

+0

나는 그것이 잔인하다고 생각하지만, 파이썬에서 단위 테스트를 사용하는 법을 배우기를 원한다. 나는 또한 다른 사람의 코드를 참조하지 않고 내 작업을 점검 할 수 있기를 바랍니다. 기본적으로 나는 단지 내 알고리즘과 관련하여 올바른/틀린 설명을 원한다. – Daenyth

+0

나는 완전히 동의한다고 말할 수 없다. 이전 질문에 부분적으로는 이것이 사실입니다. 하지만 상황이 더욱 복잡해지고 구성 요소를 더 세분화해야 할 때 개별 구성 요소를 테스트해야합니다. 물론 어떤 사람들은 질문에 답하기 위해 매우 짧은 프로그램을 작성할 수 있습니다. 그렇다면 답은 옳습니다. 그러나 대부분의 (사람) 사람들은 문제를 더 작은 덩어리로 분해 할 것입니다. –

2

예, 당신이 할 수있는 설정 테스트 데이터에 대한 단위 테스트를 그들이 주기.

파이썬을 사용하여 문제를 해결하는 것처럼 보입니다. 다른 구성 요소의 유효성을 확인하기 위해 수행하는 작업은 예제 데이터에 대해 간단한 'assert'문을 수행하는 것입니다. 그것은 잘 작동하고 시간 오버 헤드가 적습니다. 게다가 문제 30의 새로운 변경 사항이 올바른지 알아야 할 때 전체 테스트 스위트를 실행할 필요가 없습니다.

Using Assertions Effectively

+0

나는 파티에 거의 3 년이나 늦었다는 것을 알고 있지만 이것은 갈 길이다. – chucksmash

1

은 내가 3 년 늦게 파티에있어 알고 있지만 나는 TDD를 통해 프로젝트 오일러에 접근하고 어떻게 공유 할 것이라고 생각했다.

저는 파이썬으로 작업하고 있습니다.

은 내가하는 일은 이것이다 :

  • 모든 문제는 (최소한) 아무리 사소한 또는 바보가 느낄 수, 입/출력 점 역할을하지 자신의 기능을 가져옵니다. 문제가 미래에 필요할 것으로 생각되는 일종의 기능이 필요할 경우에도 문제가 도우미 기능을 얻을 수 있습니다.
  • 대부분의 프로젝트 오일러 질문에는 테스트 자체에서 더 작은 데모/테스트 문제가 포함됩니다. 이 테스트 문제는 당신이 가장 해결하지만 더 작은 규모로 무엇을 설명합니다.
  • 입/출력 기능을 문제의 장난감 버전과 더 힘든 풀 스케일 버전을 모두 해결할 수있는 매개 변수로 설정하십시오. 예를 들어, problem 12에서 내 (말도 안되게 명명 된) 진입 점은 get_triangle_num_with_n_or_more_divisors (n)입니다.
  • 이 시점에서 필자는 함수를 구현하지 않았으며 방금 이름을 지정했습니다. 이제이 문제에 대한 두 가지 테스트, test_example 및 test_problem을 작성합니다. 우리가 답을 모르기 때문에 test_problem을 @unittest.skip('Unimplemented')으로 꾸밀 것입니다. 테스트 파일은 내 것처럼 보일 수 있습니다

    import unittest 
    
    from problems.p0014 import get_triangle_num_with_n_or_more_divisors 
    
    class TestHighlyDivisibleTriangleNumber(unittest.TestCase): 
        def test_example(self): 
         self.assertEquals(get_triangle_num_with_n_or_more_divisors(1), 
              1) 
         self.assertEquals(get_triangle_num_with_n_or_more_divisors(2), 
              3) 
         self.assertEquals(get_triangle_num_with_n_or_more_divisors(6), 
              28) 
    
        @unittest.skip('Unimplemented') 
        def test_problem(self): 
         self.assertEquals(get_triangle_num_with_n_or_more_divisors(500), 
              'TODO: Replace this with answer') 
    

이제 프로젝트 오일러, TDD 스타일을하고 있습니다. 예제 코드를 사용하여 구현 코드를 테스트하고 있습니다. 실제로 유일한 방법은 구현 버전을 실제 버전과 실제 버전 모두를 해결하는 데 사용할 수있는 유연한 방법으로 작성하는 것입니다.

나는 앉아서 get_triangle_num_with_n_or_more_divisors를 작성한다. test_example이 통과되면 실제 문제를 해결하려고 시도합니다. 작동하는 경우 내 test_problem 케이스를 실제 응답으로 업데이트하고 bam 부 풀리기 회귀 테스트가 있습니다.

Hackerrank,하는 Project Euler section이있는 TDD 패러다임에 의해 진행됩니다

0

생각 나는 나의 접근 방식을 공유하고자합니다. 알고리즘 알 수 없음 테스트 케이스를 사용하여 점수를 매겼습니다. 첫 번째 샘플 테스트 케이스를 제공하여 시작을 유도합니다. 오프라인으로 개발하고 내 솔루션의 유효성을 검사하여 좀 더 빠르고 정확한 피드백을 얻기 위해 다른 테스트 사례를 작성합니다.

어디에서 이러한 사례를 얻을 수 있습니까? 당신은 손으로 그것들을 할 수 있으며 아마도 로컬에서 실행되는 자신의 무차별 강제 코드에서 생성 할 수 있습니다. 이것의 아름다움은 실제 사례 시나리오에서 더 일반적인 가장자리 케이스를 설명해야한다는 것입니다. 자바 스크립트 테스트

예 :

var cases = [ 
    {input: '1\n15', output: '45'}, 
    ... 
]; 

describe('Multiples of 3 and 5', function() { 
    cases.forEach((v, i) => { 
    it('test case #' + i, function() { 
     assert.equal(unit(v.input), v.output); 
    }) 
    }); 
}); 

Hackerrank는 표준 입력과 표준 출력을 사용하지만, 난 여전히 기능으로 메인 코드를 분리하고 함수형 프로그래밍을 사용하려고합니다.

관련 문제