저수준 구성 요소에서 TDD를 수행하는 것이 좋습니다?

저수준 드라이버 또는 OS 구성 요소 / 커널 작성을 고려하고 있습니다.

osdev.org 사람들은 이런 식으로 중요한 부분을 의미있게 테스트 할 수 없다고 생각하는 것 같지만 사람들 이 다르게 생각하는 토론을 읽었습니다. 주변을 둘러 보았지만 저수준 구성 요소에서 TDD의 실제 예를 찾지 못했습니다.

실제로 사람들이하는 일입니까, 아니면 실제로 실천할 수있는 좋은 방법이 없기 때문에 사람들이 이론에서 말하는 것입니까?

하드웨어와 상호 작용하거나 제어하는 ​​경우 하드웨어없이 테스트하기가 어렵습니다. 하드웨어 에뮬레이션을 시도 할 수 있지만, 처음에는 드라이버를 작성하는 것보다 훨씬 어렵 기 때문에 드라이버에 버그가 있는지 또는 에뮬레이터에 있는지 알지 못합니다.

나는 개인적으로 다음과 같은 방법으로 TDD의 많은 이점을 얻을 수 있다고 믿는 경향이 있습니다.

• 둘 다 쓰기 발신자 와 수신자를 동시에 주위에 코드를 (확실히 24 시간 이상 간격).
  • 그리고 인터페이스의 디자인 (객체, 메소드 호출 및 매개 변수)에 영향을주기 위해 이것을 사용하십시오.
• 복잡한 알고리즘 / 코드가 필요한 구성 요소의 경우 효율성이 낮거나 어리 석거나 좁은 상황에서만 작동하더라도 간단하지만 올바른 알고리즘으로 먼저 구현하는 것이 좋습니다.
  • 매우 간단한 테스트 방법은 알고리즘을 모두 실행하고 결과를 비교하는 것입니다.
• 코드의 한 부분에서 (어떤 수단 으로든) 버그가 발견되면 해당 코드 부분을 훨씬 더 적극적으로 테스트 할 가치가 있습니다. 이것은 TDD가 요구하는 것보다 더 복잡한 테스트를 수행한다는 것을 의미합니다. ( 클러스터에서 버그가 발생 한다는 추론에 근거 )

TDD 는 코드를 구현하여 어떤 기능 을 구현하려고하는지 또는 어떤 요구 사항 을 충족 시키려고 하는지 명확하게 이해해야 할 것 같습니다 . 어떤 상황에서는 문제에 대한 이해가 너무 적습니다. 이것은 스파이크 솔루션을 요구했을 것 입니다. 이 스파이크 솔루션의 범위 내에서 문제가 다루기 쉬운 수준으로 좁혀 져서 TDD를 적용 할 수 있습니다. 일단 원래 문제의 일부 측면을 다루는 몇 가지 스파이크가 완료되면 전체 솔루션에 대한 작업을 시작할 수 있으며 그 시점에서 TDD를 적용하는 것이 이해의 향상으로 실현 가능할 수 있습니다.

편집 :

페이지를보다 자세히 읽은 후

"테스트 베드"테스트 드라이버에서 대부분의 커널 기능을 테스트 할 수 있어야하지만 인터럽트 처리, 프로세스 디스패치 또는 메모리 관리와 같은 실제로 "수 분이 많은"항목은 단위 테스트가 불가능합니다. --- http://wiki.osdev.org/Unit_Testing에서

그들은 명확하게 말을하는 대부분의 부품을 테스트 할 수 있습니다, 그 일부는 테스트의 다른 종류의 필요 : 스트레스 테스트를 .

난 아니야 내 마스터의 임베디드 코드에서 코드를 작성하고 코드의 기능에 대한 추론을합니다. 어쨌든 내 경우에 수행 될 수 있는지 확실하지 않습니다. 테스트 코드를 주입하지 않고 메모리의 물리적 한계에 방해가됩니다.

충분히 큰 시스템 (예 : KB가 아닌 MB의 메모리가있는 시스템)의 경우 충분한 시간과 노력이 필요한 경우 일부 구성 요소에 대해 수행 할 수 있다고 생각합니다. 핀을 조롱하여 핀 판독 코드를 테스트하는 것은 매우 의미가 없습니다. 로직을 충분히 분리했다면 다른 곳에서 로직을 테스트 할 수 있습니다.

FWIW, 나는 일반적인 경우에 TDD를 구입하지 않습니다-충분한 결정 론적 행동을 가진 충분한 리소스로 충분히 큰 시스템 스택에 적합합니다.