модулни тестови компилационни файлове

Кои са най-добрите политики за компилационни файлове за тестване на единици?

Причината да попитам е, че моята компания произвежда високонадеждни вградени устройства. Софтуерните корекции просто не са опция, тъй като тяхното разпространение струва на нашите клиенти хиляди. Поради това имаме много стриктни процедури за качество на кода (единични тестове, прегледи на код, възможност за проследяване и т.н.). Тези процедури се прилагат към нашите компилационни файлове (autotools, ако трябва да знаете, очаквам съжаление), но ако се чувства като хакване.

Ъъъ... проектът се компилира... маркирайте компилационните файлове като прегледани и тествани на модула.

Трябва да има по-добър начин. Идеи?


unit-testing cmake autotools makefile scons
person deft_code    schedule 13.05.2009    source източник

Отговори (3)


arrow_upward
6
arrow_downward

Ето подхода, който сме възприели при изграждането на голяма кодова база (много милиони редове код) в повече от дузина платформи.

  • Промените в Makefile се преглеждат от екипа за изграждане. Тези хора знаят грешките, които хората са склонни да правят в нашата среда за изграждане, и те са тези, които усещат тежестта на това, когато една компилация се повреди, така че те са мотивирани да намират проблеми.
  • Намалете до минимум това, което трябва да влезе в Makefile, така че да има по-малко възможности за грешки. Имаме слой върху make, който генерира Makefile. Разработчикът просто трябва да посочи във файла от по-високо ниво, използвайки етикети, че например дадена цел е споделена библиотека или тест на единица. Обикновено целта се дефинира на един ред, което след това води до множество настройки/цели в генерирания Makefile. Подобни неща могат да се направят с инструменти за изграждане като scons, които позволяват да се абстрахират неща като специфични за платформата подробности, правейки целите много прости.
  • Единични тестове на нашия инструмент за изграждане. Инструментът е написан на Perl, така че ние използваме Test::More модулна тестова рамка там, за да се провери дали инструментът генерира правилния Makefile, даден на нашия файл от по-високо ниво. Ако вместо това използвахме нещо като scons, бих използвал тяхната рамка за тестване.
  • Едини тестове на нашите нощни компилации/тестови скриптове. Имаме набор от скриптове, които стартират нощни компилации на всяка платформа, изпълняват инструменти за статичен анализ, изпълняват единични тестове, изпълняват функционални тестове и докладват всички резултати на централна база данни. Тестваме различните скриптове поотделно, най-вече използвайки рамката за тестване на единици shunit2 за sh/bash /ksh/и др.
  • Пълни тестове на нашия процес на компилация/тест. Работя върху тест от край до край, който работи върху малко дърво на източника, а не върху производствения ни код, тъй като последният може да отнеме часове да се изгради. Тези тестове са насочени главно към проверка дали нашите цели за изграждане все още работят и отчитат резултатите в централната ни база данни дори след като например надстроим нашия инструмент за покритие на кода или направим промени в нашите скриптове за изграждане.
person Pete TerMaat    schedule 14.05.2009

arrow_upward
2
arrow_downward

Имайте своя файл за компилация, за да компилирате известна версия на вашия софтуер (или по-проста част от код, който е подобен от гледна точка на компилация) и сравнете резултата, получен с вашите нови инструменти за компилация, с очаквания резултат (създадена с валидирана версия на инструментите за компилация ).

person philant    schedule 14.05.2009

arrow_upward
-2
arrow_downward

В моите проекти build-файловете не се променят много често. Нещо повече, мога да използвам повторно компилирани файлове от по-ранни проекти, като променям само някои променливи (които преместих в лесен за разпознаване раздел). Ето защо за мен не е необходимо да тествам модулно файловете за компилация. Това може да е различно в други проекти.

person Mnementh    schedule 14.05.2009