Bold for Delphi 프레임 워크로 코딩 할 때 테스트 가능성 향상

Question

배경 저는 7 명의 개발자와 물류 시스템에서 작동하는 2 명의 테스터로 구성된 팀에서 일합니다. 우리는 프레임 워크로 Bold for Delphi과 함께 델파이 2007 및 모델 구동 개발을 사용합니다. 이 시스템은 현재 약 7 년 동안 생산되었으며 약 1,7 수백만 줄의 코드를 가지고 있습니다. 우리는 4-5 주 후에 프로덕션으로 릴리스하고 거의 모든 릴리스 이후에 발견되지 않은 버그에 대한 패치를 수행해야합니다. 이것은 물론 우리와 고객 모두를 자극합니다.

현재 테스트 물론 해결책은 더 자동 테스트입니다. 현재 수동 테스트가 있습니다. 빈 데이터베이스로 시작하고 모델링 된 메서드에서 데이터를 추가하는 Testdbgenerator입니다. 우리는 또한 GUI 테스트를위한 아주 기본적인 스크립트를 실행하는 Testcomplete을 가지고 있습니다. 시간 부족으로 더 많은 테스트를 중단 할 수 없지만 스크립트는 애플리케이션의 변경 사항에도 민감합니다. 몇 년 전에 DUnit을 사용하여 단위 테스트를 실제로 시도했지만 몇 일 후에 단념했습니다. 장치가 너무 강하게 연결되어 있습니다.

• 한 일을 작은 방법을 쓸 수 있지만 그것을 잘 수행

  단위 테스트의 전제 조건은 내가 단위 테스트에 대한 몇 가지 전제 조건을 알 것 같아요.

• 반복하지 마십시오.
• 먼저 실패한 테스트를 작성한 다음 테스트를 통과하도록 코드를 작성하십시오.
• 단위 사이의 연결이 느슨합니다. 그들은 서로에 대해 많이 알지 않아야합니다.
• 의존성 주입을 사용하십시오.

프레임 워크는 우리는 주로하기 때문에 64 비트 컴파일러의 델파이 XE2로 업그레이드 할 수 있습니다 사용할 수 있습니다. Spring을 조금 보았습니다. 그러나 D2007의 업데이트가 필요하며 지금은 발생하지 않습니다. 아마도 내년에.

질문 중 대부분의 코드는 자동으로 테스트되지 않습니다. 그렇다면 오래된 코드의 테스트 가능성을 높이기위한 최선의 경로는 무엇입니까? 아니면 새로운 방법에 대해서만 테스트를 작성하는 것이 가장 좋습니다. 자동 테스트를 늘리는 가장 좋은 방법은 무엇인지 잘 모르겠습니다. 그리고 그에 대한 의견은 환영합니다. D2007 + DUnit을 사용하고 나중에 쉽게 Delphi XE2 + Spring으로 변경할 수 있습니까?

편집 : 수동 테스트를위한 현재의 테스트 방법론은 바로 "파운드를 떼어 놓으려고 시도합니다."라고 말하면서 Chris이라고 부릅니다.

Answer 1

Michael Feathers가 Working Effectively with Legacy Code로 책을 원한다. 테스트 가능성을 염두에두고 작성되지 않은 코드에 (단위) 테스트를 도입하는 방법을 보여줍니다.

개발자가 예전의 코드를 테스트하는 것이 어려운 이유에 대한 줄 수도, 그들은 사례 연구를 포함하고 각각의 문제를 해결하는 방법을 제안 변명 명명 된 장 중 일부 :

• 나는 많은 시간을 필요는 없습니다 나는 내가 테스트 장치에서이 방법을 실행할 수 없습니다 그것을
• 을 변경해야
• 이 클래스는 너무 크고, 나는 그것을 얻을 싶지 않아 내가 괴물 방법을 변경해야
• 있는 더 크고 더 나는 그것을위한 시험을 쓸 수 없다.

또한 종속성을 제거하는 많은 기술을 다룹니다. 어떤 것은 당신에게 새로운 것이거나, 당신이 이미 알고 있을지도 모르지만 아직 사용하지 않을 생각이있는 사람들도 있습니다.

Answer 2

테스트 팀이 너무 작습니다. IMO. QA 부서가 개발자보다 많은 팀에서 일했습니다. 더 작은 사이클에 적합한 관리 가능한 덩어리 (기능, 수정)의 "스프린트"작업을 고려하십시오. "애자일"은 2 주간의 스프린트를 장려하지만 너무 빡빡 할 수 있습니다. 어쨌든 QA는 계속해서 바쁜 상태로 유지되며 릴리스 윈도우보다 먼 앞으로 작업합니다. 지금 당장은 코드를 엄청나게 줄 때까지 유휴 상태라고 생각합니다. 릴리스주기가 짧으면 더 많은 테스터를 사용할 수 있습니다.

또한 테스트 방법에 대해 많이 말하지 않았습니다.표준 스크립트를 사용하여 예상되는 모양과 동작에 대한 모양과 동작을 확인합니다. 아니면 그들은 그것을 "깨뜨리려고 노력"합니까?

IMO, Dunit 테스트는 데이터베이스, 통신 등과 같은 많은 의존성으로하기가 어렵습니다.하지만 할 수 있습니다. 데이터베이스 설정 스크립트를 자동으로 실행하는 DUnit 클래스를 만들었습니다. 테스트 할 클래스와 이름이 같은 .sql 파일을 찾고 SQL을 실행 한 다음 테스트가 진행됩니다. 매우 효과적입니다. SOAP 통신의 경우, Canap 결과를 반환하는 SoapUI mockservice를 실행 중이므로 통신을 테스트 할 수 있습니다.
그것은 효과가 있지만 그만한 가치가 있습니다. 자동화 된 단위 테스트에 대한

Answer 3

요구 사항은 정확히이 있습니다

1. (예를 들어,은 DUnit을)를 단위 테스트 프레임 워크를 사용합니다.
2. 일종의 조롱 프레임 워크를 사용하십시오.

항목 2는 힘든 항목입니다.

DRY, 작은 방법, 시험으로 시작, DI는 모두 설탕입니다. 먼저 단위 테스트를 시작해야합니다. DRY 등을 추가하십시오. 커플 링이 줄어들면 유닛 테스트가 더 쉽게 이루어 지지만 거대한 리팩토링 노력 없이는 기존 코드 기반의 커플 링을 줄일 수 없습니다.

새로운 항목 및 릴리스에서 변경된 항목에 대한 작성 테스트를 고려하십시오. 시간이 지남에 따라 합리적인 단위 테스트를받을 수 있습니다. 새롭고 변경된 내용은 리팩토링 (또는 잘 작성) 될 수 있습니다.

또한 단위 테스트를 실행하고 빌드가 중단 될 때 이메일을 보내는 자동화 된 빌드 프로세스를 고려해보십시오.

여기에는 단위 테스트 만 포함됩니다. QA 테스터에게는 단위 테스트가 아닌 자동화 된 테스트를 실행할 수있는 툴 (존재하지만 생각할 수는 없습니다)이 필요합니다.