Здравствуйте.

Вот имеется отдельная машина на которой гоняются интеграционные тесты -- где-то ~1 часа времени занимает. По результатам хотелось бы на почту или куда-то
получать сообщение об возникших ошибках и лог прогона. Можно подключить TC, но он больше для коммитов, что тоже полезно. Пока что вижу выход в
отправке себе сообщений по почте.

Далее, в коде, в отладочной версии над которой гоняются тесты есть места типа:

#if DEBUG
                try
                {
                  // code
                }
                catch(InvalidOperationException e)
                {
                    Debugger.Launch();
                    throw;
                }
#else

Если произошло исключение, хотелось бы быть в курсе данного события, чтобы не простаивать. Т.е. надо бы асинхронно известить разработчика перед запуском отладчика.

Кто как подобные проблемы решает? Просто подрубает System.Net.Mail и вперед или же есть какие-то устоявшиеся решения и практики?

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

S>Вот имеется отдельная машина на которой гоняются интеграционные тесты -- где-то ~1 часа времени занимает. По результатам хотелось бы на почту или куда-то
S>Кто как подобные проблемы решает? Просто подрубает System.Net.Mail и вперед или же есть какие-то устоявшиеся решения и практики?
Наверное, в зависимости от того, чем прогоняете тесты.
У нас это всё на bamboo — у него есть свои средства, плюс кое-где свои сообщения шлём в Slack.

Думаю вам мешает запуск отладчика — не уверен, что это хорошая практика. Тест должен быть зелёным или красным — а траблшутинг это отдельная задача.

S>Кто как подобные проблемы решает?
Имхо, сейчас мало кто пишет с нуля собственную инфраструктуру по запуску тестов.
Берут готовый CI/DI сервер (TeamCity, Jenkins, Bamboo, GitLab CI и т.п.).
Это сразу снимает кучу вопросов:
-Отслеживание изменений в source control
-История запуска тестов
-Хранение артефактов (логи, дампы, документы и т.п.)
-Web-интерфейс для просмотра/запуска/остановки тестов
-Расписание и триггеры запуска (скажем, каждую ночь или по коммиту)
-Уведомления (email, SMS, всяко-разные мессенджеры)

Разработчику (или тестировщику) при этом остается выбрать язык/фреймворк и собственно фигачить тесты.

S>Если произошло исключение, хотелось бы быть в курсе данного события, чтобы не простаивать. Т.е. надо бы асинхронно известить разработчика перед запуском отладчика.
Вот эта условная компиляция с запуском дебагера — для меня вообще какой-то дикий кейс.
Что должен делать разработчик, когда в час ночи ему вдруг пришло письмо об упавшем тесте?
Срочно бежать к компу и подрубаться Remote Debugger'ом к удаленной машине?

Имхо правильные тесты должны быть полностью автоматическими, т.е. не требовать участия человека от слова совсем.
А тест репорт должен быть достаточно подробным, чтобы разработчик мог понять, что конкретно произошло.
Кроме того, у разработчика должна быть возможность прогнать те же тесты локально (или на спец.выделенной среде) как раз для отладки.
Тогда получается логичная картинка: ночью тесты запустились, утром человек пришел, увидел что они красные, посмотрел лог запуска, понял где проблема,
запустил локально отладчик, воспроизвел и починил.

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

S>>Кто как подобные проблемы решает?
RD>Имхо, сейчас мало кто пишет с нуля собственную инфраструктуру по запуску тестов.
RD>Берут готовый CI/DI сервер (TeamCity, Jenkins, Bamboo, GitLab CI и т.п.).
RD>Это сразу снимает кучу вопросов:
RD>-Отслеживание изменений в source control
RD>-История запуска тестов
RD>-Хранение артефактов (логи, дампы, документы и т.п.)
RD>-Web-интерфейс для просмотра/запуска/остановки тестов
RD>-Расписание и триггеры запуска (скажем, каждую ночь или по коммиту)
RD>-Уведомления (email, SMS, всяко-разные мессенджеры)

RD>Разработчику (или тестировщику) при этом остается выбрать язык/фреймворк и собственно фигачить тесты.


Я выше написал, что в случае CI\DI будет единичный запуск по коммиту. А мне нужна возможность гонять интеграционные тесты на регулярной основе, вне зависимости от CI\DI.

S>>Если произошло исключение, хотелось бы быть в курсе данного события, чтобы не простаивать. Т.е. надо бы асинхронно известить разработчика перед запуском отладчика.
RD>Вот эта условная компиляция с запуском дебагера — для меня вообще какой-то дикий кейс.
RD>Что должен делать разработчик, когда в час ночи ему вдруг пришло письмо об упавшем тесте?
RD>Срочно бежать к компу и подрубаться Remote Debugger'ом к удаленной машине?

Согласен. Но в моем случае владелец кода я, и бежать никуда не надо. По извещение об этом событии просто подключаюсь отладчиком к удаленной машине.
Таких мест в коде немного, пока вообще одно. Суть в том, что у меня там гейзенбаг, где, как мне кажется (почти уверен), работает один поток с коллекций,
а вылетает исключение типа "Collection was modified while enumerating...". Просить code review некого, я один работаю над проектом. У меня глаз замылен, не вижу
места для ошибке в том коде... Остается одна надежда поймать что-нибудь отладчиком и взять dump.



RD>Имхо правильные тесты должны быть полностью автоматическими, т.е. не требовать участия человека от слова совсем.
RD>А тест репорт должен быть достаточно подробным, чтобы разработчик мог понять, что конкретно произошло.

Можно результат прогона тестов, т.е. что упало и логи прогона.

S>Я выше написал, что в случае CI\DI будет единичный запуск по коммиту. А мне нужна возможность гонять интеграционные тесты на регулярной основе, вне зависимости от CI\DI.
Не берусь говорить за все упомянутые CI, но тот же TeamCity, например, позволяет очень гибко настраивать триггеры запуска.
Можно сделать по коммиту, можно периодически, а можно отключить триггеры и запускать руками по необходимости.

S>>>Если произошло исключение, хотелось бы быть в курсе данного события, чтобы не простаивать. Т.е. надо бы асинхронно известить разработчика перед запуском отладчика.
RD>>Вот эта условная компиляция с запуском дебагера — для меня вообще какой-то дикий кейс.
RD>>Что должен делать разработчик, когда в час ночи ему вдруг пришло письмо об упавшем тесте?
RD>>Срочно бежать к компу и подрубаться Remote Debugger'ом к удаленной машине?

S>Согласен. Но в моем случае владелец кода я, и бежать никуда не надо. По извещение об этом событии просто подключаюсь отладчиком к удаленной машине.
S>Таких мест в коде немного, пока вообще одно. Суть в том, что у меня там гейзенбаг, где, как мне кажется (почти уверен), работает один поток с коллекций,
S>а вылетает исключение типа "Collection was modified while enumerating...". Просить code review некого, я один работаю над проектом. У меня глаз замылен, не вижу
S>места для ошибке в том коде... Остается одна надежда поймать что-нибудь отладчиком и взять dump.
RD>>Имхо правильные тесты должны быть полностью автоматическими, т.е. не требовать участия человека от слова совсем.
RD>>А тест репорт должен быть достаточно подробным, чтобы разработчик мог понять, что конкретно произошло.
S>Можно результат прогона тестов, т.е. что упало и логи прогона.

Ну ОК. Сложно предложить что-то стоящее, не зная всех деталей, но, если делать руками, то у меня было бы как-то так:
1. Пишем тесты, собираем в виде DLL
2. Пишем простейший скрипт автоматизации (bash, cmd, PowerShell, CMake, Fake, etc), который
— Создает папку для хранения реквизитов, e.g. TestRun_yyyy-MM-dd-hh-mm-ss
— Запускает тест-ранер, настроив его на запись тест-логов в эту папку
— Падающий тест должен автоматически сделать process dump и сложить в ту же папку
— По окончанию прогона — если в папке есть дампы, архивируем ее и шлем себе для разбора

Это если все-таки автоматизировать.
Но в твоем случае возможно будет проще тупо с утра запустить тесты на множественный прогон в отдельном экземляре VS на локальной машине.
Когда она встанет в debugger-сразу увидишь.

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

S>>Я выше написал, что в случае CI\DI будет единичный запуск по коммиту. А мне нужна возможность гонять интеграционные тесты на регулярной основе, вне зависимости от CI\DI.
RD>Не берусь говорить за все упомянутые CI, но тот же TeamCity, например, позволяет очень гибко настраивать триггеры запуска.

Интересно, надо будет поизучать.

RD>Можно сделать по коммиту, можно периодически, а можно отключить триггеры и запускать руками по необходимости.

Это как раз мой случай.

RD>Ну ОК. Сложно предложить что-то стоящее, не зная всех деталей, но, если делать руками, то у меня было бы как-то так:
RD>1. Пишем тесты, собираем в виде DLL
RD>2. Пишем простейший скрипт автоматизации (bash, cmd, PowerShell, CMake, Fake, etc), который
RD>- Создает папку для хранения реквизитов, e.g. TestRun_yyyy-MM-dd-hh-mm-ss
RD>- Запускает тест-ранер, настроив его на запись тест-логов в эту папку
RD>- Падающий тест должен автоматически сделать process dump и сложить в ту же папку

И как это сделать на лету, чтобы при исключении оттормозить приложение, сделать дамп и продолжить работу?

RD>Но в твоем случае возможно будет проще тупо с утра запустить тесты на множественный прогон в отдельном экземляре VS на локальной машине.
RD>Когда она встанет в debugger-сразу увидишь.

Увы нет, тесты длятся около часа и при этом загрузка CPU ~100%(мат. расчеты, работа с матрицами и т.д.). Соотв. рабочая машина будет дико тормозить.
Поэтому и необходимо все делать удаленно и получать извешения о результатх прогона или необходимости подключить отладчик.

S>И как это сделать на лету, чтобы при исключении оттормозить приложение, сделать дамп и продолжить работу?
Ну как-нибудь так, например:

[DllImport(@"dbghelp.dll")]
public static extern bool MiniDumpWriteDump(IntPtr hProcess,
    Int32 processId,
    IntPtr hFile,
    int dumpType,
    IntPtr exceptionParam,
    IntPtr userStreamParam,
    IntPtr callbackParam);

[Test]
public void DumpMe()
{
    using (var fs = File.OpenWrite(@"D:\temp\dump.bin"))
    {
        var process = Process.GetCurrentProcess();
        MiniDumpWriteDump(process.Handle,
            process.Id,
            fs.SafeFileHandle.DangerousGetHandle(),
            0x1826 /* Это пример, флаги смотри сам в документации к Win API*/,
            IntPtr.Zero,
            IntPtr.Zero,
            IntPtr.Zero);
        fs.Flush(true);
        fs.Close();
    }
}

Или можно procdump взять и запускать его как внешний процесс

var p = Process.Start(new ProcessStartInfo("procdump", $"-ma {Process.GetCurrentProcess().Id}") /* Флаги смотри сам */);
p.WaitForExit();