RUnit, 및 testthat과 같은 도구가 패키지 개발자에게 유용하지만 특정 테스트 패키지 또는 특정 패키지의 사용 예제를 업로드하는 데 유용 할 것으로 생각됩니다. 지속적인 통합 (예 : Jenkins) 또는 기본 단위 테스트를 수행하는 사용자는 이미 이러한 테스트를 수행하고 있으며 패키지 유지 관리자의 사용을 위해 스크립트를 제공하는 것이 도움이 될 수 있습니다.R 테스트 스크립트 제공
CRAN 또는 RForge를 통해 또는 github과 같은 다른 사이트를 통해 이러한 기능이 있습니까? 그렇다면 저장소를 사용하는 주요 예가 있습니까 (예 : 사용자가 테스트에 참여할 수있게하려면 github?
(덕분에 svUnit의 저를 생각 나게 @mariotomo합니다.)
나는 일을과 복잡함을 자제하는 것이 좋습니다 것입니다. 왜 그냥 이런 식으로 뭔가 : 주어진 패키지의 소스에서
봐 (즉 rforge, rforge, github에 ... 또는 직선 크랑 소스에),
을 (그 testings를 방식을 이해 예 : tests/ 디렉토리, 매뉴얼 페이지의 예 또는 CRAN의 세 가지 단위 테스트 프레임 워크 중 하나) 및
은 새로운 테스트에 기여합니다.
정말 그게 전부입니다. 공헌 문서, 데모 스크립트, 새 코드와 동일합니다 ... 오픈 오픈 소스에 집중할 수 있습니다.
+1 좋은 조언. 나는'tests /'디렉토리를 간과했다. 나는 다른 사용자가 테스트에 영향을 미치는지 여부에 관계없이 테스트를 의미했다. (예를 들어 작성자가 특정 테스트가 중단 된 경우에도 변경 사항을 의도하는 경우) 다른 사용자에게 유용합니다. 업그레이드 된 패키지를 사용하기 전에 사용자 측에서 감독하고 검증 단계의 일부로'test /'결과를 통합하지 않았습니다. 아주 좋은 알림 주셔서 감사합니다. – Iterator
즐거움. 작은 점진적인 기부에 대한 귀하의 요청은 작고 실천 가능한 일에 중점을두고 있습니다. –
패키지의 작은 샘플에서 발견 한 한 가지 주름은 내 작업에 중요한 몇 가지 요소 임에도 불구하고 R 코어 또는 적어도 모범적 인 개발자가'tests /'디렉토리를 사용하는 개발자가있을 가능성이 높습니다. 나머지는 매우 견고한 연구자들이 썼지 만 개발에 대한 전문 지식이별로 없을 수도 있습니다. 테스트를 여러 패키지 관리자에게 전달하는 것이 더 나은지 또는 저장소에있는 여러 패키지에 대한 테스트를 게시하는 것이 더 나은지 궁리해야합니다. – Iterator
R 및 기타 언어의 경우 정말 좋습니다. – Owen
몇 사람이 github에 대한 요청을 풀어 테스트에 참여하게했습니다 – hadley
svUnit을 잊지 마세요! :) 젠킨스 내에서 꽤 멋지 네요. – mariotomo