у тебя ж асерёт кинет ексепшун в репл если что-то не так

Вот собственно с раннером я и пытаюсь разобраться. Эксепшоны не хочу, хочу красивый аутпут :3

Заранее простите за нубский вопрос. А кто-нибудь знает, как запустить NUnit тесты непосредственно из кода? То есть не хочу делать dotnet test, хочу скомпилировать бинарник который буду запускать, который и будет прогонять тесты с выводом и все вот это вот

Советую посмотреть код из их родного test runner. Наверняка там и API есть.

тогда не понимаю чем тебя dotnet test не устроил))

тогда не понимаю чем тебя dotnet test не устроил))

тычоа - это же Microsoft :)

он же ранер запускает, дискаверит тесты, гоняет, выводит красивый аутпут

тогда не понимаю чем тебя dotnet test не устроил))

Хочу сделать нативный бинарник который можно будет засунуть в докер. А microsoft/dotnet:2.1-sdk почти 2 гига жрет

я думал тебе не хочется гонять ВСЕ тесты, тогда да, fsx делаешь и гоняешь отдельным кусками

тычоа - это же Microsoft :)

Дак и fsi — Microsoft.

Поэтому хочу отказаться от dotnet test и сделать через бинарник

Дак и fsi — Microsoft.

я уретрирую :)

Не то, чтобы это критично. Но такое решение мне кажется более... симпатичным что ли :)

Хочу сделать нативный бинарник который можно будет засунуть в докер. А microsoft/dotnet:2.1-sdk почти 2 гига жрет

А расскажи больше про свой workflow.

я уретрирую :)

Опечатка?

Вообще не совсем понятно, зачем тесты пихать в докер

Поэтому хочу отказаться от dotnet test и сделать через бинарник

Тебе же всё равно тесты нужно компилировать, то есть SDK у тебя есть.

Опечатка?

да, наверное ;)

Вообще не совсем понятно, зачем тесты пихать в докер

Чтоб после Билда исполнялись

Тебе же всё равно тесты нужно компилировать, то есть SDK у тебя есть.

видимо, тесты интеграционные

Вообще не совсем понятно, зачем тесты пихать в докер

Щас я ему всё расскажу, не боись.

Ну, есть набор тестов, которые шлют всякие рест запросики и ассертят статус коды и контент. Сделано на NUnit.Framework и FsUnit для ассертов. Солюшн — Class Library. Сейчас запускаю либо через консоль dotnet test либо через райдер с NUnit3TestAdapter

Ну, есть набор тестов, которые шлют всякие рест запросики и ассертят статус коды и контент. Сделано на NUnit.Framework и FsUnit для ассертов. Солюшн — Class Library. Сейчас запускаю либо через консоль dotnet test либо через райдер с NUnit3TestAdapter

Пока всё в порядке.

Вообще не совсем понятно, зачем тесты пихать в докер

Чтобы на CI их исполнять

Чтобы на CI их исполнять

На CI тоже есть SDK, верно?

На CI тоже есть SDK, верно?

Пока нет. И не хочу туда тащить его без особой надобности

Вообще тесты на ф# это самодеятельность в целях проверки пригодности идеи. Так что пока я немного ограничен в ресурсах

Пока нет. И не хочу туда тащить его без особой надобности

а как билдишь-то?

если ты хочешь порекламить F# то лучше делать максимально просто, чтобы не вызывало оторопь

Пока все делаю локально. Написал тесты, запустил, прогнал

при этом желательно по максимум использовать доступные интеграции. Т.е. "здесь можно делать как привыкли", а не "а чтобы сделать тест аутпут, я написал свою либу" :)

при этом желательно по максимум использовать доступные интеграции. Т.е. "здесь можно делать как привыкли", а не "а чтобы сделать тест аутпут, я написал свою либу" :)

Ну у меня пока максимально просто с самим кодом :) хочу разобраться с инфраструктурой

Пока нет. И не хочу туда тащить его без особой надобности

А кау ты без SDK будешь собирать проект?

И ещё расскажи, мил человек, накой тебе докер для билд агента?

Учитывая, что их обычно около трёх

И ещё расскажи, мил человек, накой тебе докер для билд агента?

Мб у него весь пайплайн в контейнерах, это норм.

Мб у него весь пайплайн в контейнерах, это норм.

Я просто слишком стар для всего этого

И ещё расскажи, мил человек, накой тебе докер для билд агента?

У нас пайплайн такой. Что тесты в своем реджистри лежат и прогоняются при коммитах на основном проекте

У нас пайплайн такой. Что тесты в своем реджистри лежат и прогоняются при коммитах на основном проекте

Тогда тащи СДК в контейнер

2гб

И?

В идеале я хочу легковесный контейнер с бинарником тестов

Это называется overengineering

Проблем получишь больше

Потому что сейчас тесты на питоне в контейнере занимают не много места и если я предложу тесты на ф# в контейнере на 2гб на меня странно посмотрят :3

не, ну есть консольные ранеры для nunit/xunit, но лично я, лично я, не стал бы без крайней необходимоисти их пользовать

Да все равно бинари с исходниками разъедутся

Зуб даю

Ну если при каждом пуше в репчик с тестами билдить их и складывать в реджистри то не разъедутся

Но да, тут встанет вопрос с сдк

Либо на раннер ставить либо билдить в отдельном контейнере, опять же на 2гб

не, ну есть консольные ранеры для nunit/xunit, но лично я, лично я, не стал бы без крайней необходимоисти их пользовать

Я видел упоминания этой штуки, но не нашел нигде доков

Есть expecto ещё

Я видел упоминания этой штуки, но не нашел нигде доков

http://nunit.org/docs/2.5.8/consoleCommandLine.html

Тебе же параметризованные тесты нужны

http://nunit.org/docs/2.5.8/consoleCommandLine.html

лол, 1мс разницы

LMGIFY :)

https://stackoverflow.com/a/33919006/4346877

http://nunit.org/docs/2.5.8/consoleCommandLine.html

А на третий на гитхабе одна скудная страничка с текстом

Есть expecto ещё

Да, можно попробовать его. Посмотрю тоже.

А на третий на гитхабе одна скудная страничка с текстом

там вроде всё то же самое, только имя бинарника поменялось

Вообще я nunit выбрал по старой памяти с с#

Есть конечно и другие фреймворки, можно их попробовать

Короче, тебе нужен экзешник, который из условной csv прогоняет запросы

Как я понял

Короче, тебе нужен экзешник, который из условной csv прогоняет запросы

Можно даже без csv

Просто набор тестов

Ну без ты теряешь вариативность

И возможность подбацать без редеплоя

кстати, multistage build решает твою проблему с весом

билдишь тесты в dll в полном sdk, забираешь артефакт на другой стейдж в дохлый рантайм, где исполняешь и получаешь красивый аутпут

с 2ГБ до 200мб можно ужать

билдишь тесты в dll в полном sdk, забираешь артефакт на другой стейдж в дохлый рантайм, где исполняешь и получаешь красивый аутпут

О, попробую завтра такой вариант

FROM microsoft/dotnet:2.0-sdk AS build COPY . ./docker-size-test WORKDIR /docker-size-test/ RUN dotnet build -c Release -o output FROM microsoft/dotnet:2.0-runtime AS runtime COPY --from=build /docker-size-test/output . ENTRYPOINT ["dotnet", "docker-size-test.dll"]

билдишь тесты в dll в полном sdk, забираешь артефакт на другой стейдж в дохлый рантайм, где исполняешь и получаешь красивый аутпут

не надо дохлого рантайма - dotnet publish

не надо дохлого рантайма - dotnet publish

это я про докер

под таргет платформу

паблиш сам, что надо от рантайма возьмёт

он селф-контаинед

паблиш сам, что надо от рантайма возьмёт

dotnet publish рантайм не копирует вроде

я прогнал - мы же всё равно через dotnet test собираемся запускаться

билдишь тесты в dll в полном sdk, забираешь артефакт на другой стейдж в дохлый рантайм, где исполняешь и получаешь красивый аутпут

+

dotnet publish рантайм не копирует вроде

The dotnet publish command's output is ready for deployment to a hosting system (for example, a server, PC, Mac, laptop) for execution. It's the only officially supported way to prepare the application for deployment. Depending on the type of deployment that the project specifies, the hosting system may or may not have the .NET Core shared runtime installed on it.

ну т.е. с каким-то флагом, оно копирнёт рантайм, да. по дефолту вроде нет

-c=Release -r=win10-x64 например

Есть конечно и другие фреймворки, можно их попробовать

Лень/некогда погружаться в эту девопс эпопею, но из того что понял складывается ощущение, что надо юзать Expecto. Периодически юзаю его из fsx (и не только). В нем тесты изначально являются объектами с некоторым набором свойств.

Лень/некогда погружаться в эту девопс эпопею, но из того что понял складывается ощущение, что надо юзать Expecto. Периодически юзаю его из fsx (и не только). В нем тесты изначально являются объектами с некоторым набором свойств.

Хорошо, поизучаю его подробнее :)

Хорошо, поизучаю его подробнее :)

Сразу после opеn Expecto открывай open Expecto.Flip. Вернет нормальный порядок.

https://github.com/dbrattli/Fable.Reaction

Похвастаюсь) Сделал сегодня в жирафа пуллреквест

Похвастаюсь) Сделал сегодня в жирафа пуллреквест

Ого. Нас теперь двое!

Похвастаюсь) Сделал сегодня в жирафа пуллреквест

ёёёёё :)

=) посмотрим как зайдет) https://github.com/giraffe-fsharp/Giraffe.Razor/pull/7

Делал кто пакеты для fable?

Всмысле паблишил?

Там же не дллку паблишил надо, я немного хз чего публиковать-то

Там же не дллку паблишил надо, я немного хз чего публиковать-то

Помогите плз кто-нибудь как прочтет. В гиттере уже вопрос задал

http://fable.io/blog/Paket-integration.html