Че-то я всей этой системы с positive-negative и номерками не понимаю.

Может есть какой-то readme или что-то в этом духе?

Здравствуйте, catbert, Вы писали:

C>Че-то я всей этой системы с positive-negative и номерками не понимаю.
Насколько я знаю, там какой то четкой нумерации нет, раньше они нумеровались по гуглкод багтрекеру, какие то относящиеся к фичам шли без номеров от самого начала создания. Потом иссью нумеруются сейчас по гит номеру Issue-git-0219.n этого бывает достаточно, ну или можно расширенно написать название теста фичи match-classes-wo-where.n я думаю никто не обидится.

C>Может есть какой-то readme или что-то в этом духе?
Ходячим readme можно считать Влада, или кого то из нас, часто проще по скайпу в чате дать вопрос и получить ответ, таких вопросов в день может быть сотни, форума не хватит

Дописал это сообщение и понял, что у нас уже есть эта тема

Автор: VladD2
Дата: 24.06.08

в FAQ. Там более живое, но менее полное и менее формальное описание.

C>Че-то я всей этой системы с positive-negative и номерками не понимаю.

C>Может есть какой-то readme или что-то в этом духе?

Нужно использовать следующее соглашение для имен файлов тестов Issue-git-0<номер issue>[-lib].n
Где вместо <номер issue> нужно подставить номер issue с github-а, а [-lib] (без квадратных скобок) — это необязательный суффикс позволяющий отличить, что получаемая сборка должна быть длл-ю которую планируется использовать в другом тесте. При этом тест который использует [-lib]-сборку нужно называть так же, но без суфикса [-lib].

Далее все просто. В positive находятся тесты которые должны успешно скомпилироваться и выполниться. В negative те что выдают сообщения об ошибках.

Успешная компиляция контролируется или самим фактом скомпилированности, или (что лучше) сравнением консольного выхлопа со строками размещенными в комментарии:

/*
BEGIN-OUTPUT
здесь должен быть консольный выхлоп (не забывайте про локаль!)
END-OUTPUT
*/

В негативных тестах ожидаемые сообщения об ошибках должны быть указаны в комментарии в формате:

// E: регулярное выражение описывающее текст сообщения об ошибке (error)
// W: регулярное выражение описывающее текст предупреждения (warning)
// H: регулярное выражение описывающее текст подсказки (hint)
// OK

Обратите внимание, что указывается не текст, а регулярное выражение. Значит разные скобки и другие активные в регексах символы нужно эскейпить с помощью слеша — \

OK применяется в случае, если в файле и так море ошибок и все их описывать не охота. Тогда в строках где точно не должно быть ошибок указывается OK. Ну, а строки без OK, E, W или H игнорируются.

Опции компиляции можно задавать с помощью спец-комментариев:

// REFERENCE: имя сборки из GAC
// REFERENCE: путь к сборке (запрещается задавать полные пути или пути ведущие вне каталога немерла)
// OPTIONS: ключи командной строки

Примеры ищите в имеющихся тестах.

Собственно я все это изучил изучая сами тесты. Так что если что-то не ясно, то первым делом нужно пробовать поиск или просмотр тестов.