Это общее правило. Такое требование противоречит общепринятому паттерну, поэтому оно будет нарушаться. Если же заменить его на более строгое — например, на те же аттрибуты, которые уже используются для похожих целей, то соглашение пропадает, а решение остается.
Это «мусор» по вашей классификации. Такие коментарии не несут смысловой нагрузки, елси вы не пишете framework. Он только загрязняет код.
И, имхо, смешивать логику и коментарии, не слишком удачная идея. Вдруг в каком-то месте придется написать что-то, относящееся именно к коду — это сразу же вылетит на UI, чего быть не должно.
Комментарии бесполезны в таком виде «Выполнение действия», «Контекст действия». Это понятно и из имени метода, и из типа параметра. А текст должен браться из атрибутов, иначе огребете при попытке локализации.
NBehave немного заточили для NUnit, теперь типичный тест выглядит приблизительно вот так:
[Test]
public void ShouldShowCorrectEntityStatesInDropDownListWhenAddNewBug()
{
@"Scenario: Should Show Correct Entity States In Drop Down List When Add New Bug
Given project 'Project1' for process 'All Practices' created
When user 'admin' logged in via login page
And navigate to add new bug page
Then add/edit Bug page should contain states: Open, Fixed, Invalid, Closed
".Execute(In.GlobalContext());
}
nUnit — xUnit, moq — rhino — не вижу смысла менять шило на мыло.
Миша, расскажи, пожалуйста, как ты представляешь первый пункт. Имхо, Product Owner — это очень большой объем работы, именно он должен знать, куда развивается отрасль, какие фичи нужны, а какие нет…
Используем, конечно. Но в силу специфики процессов — далеко не полностью. На последней нашей внутренней конференции была замечательная презентация от нашего Product Specialist, как наши заказчики видят наш продукт. Достаточно интересно.
В сторону Entity Framework не смотрели, потому что старая модель слишком уж «богатая», переписывать ее нет смысла — новый UI использует наш маленький «ORM», в будущем, надеюсь, получится выкристализовать бизнес правила и уйти от хибернейта полностью — куда, пока не ясно. Jenkins vs TeamCity — выбор был в пользу Jenkins из-за его бесплатности — под дженкинсом сейчас крутятся 35 виртуалок. Для unit тестов — NUnit, NBehave, Rhino.Mocks, Selenium Web Driver, IronPython. Еще T4 — очень много генеренных тестов (~1000).
Юнит тесты запускаются параллельно в 8 пачках, по 6 минут на пачку где-то.
Миграция проходила достаточно гладко, сейчас новые тесты пишутся на WebDriver, старые нестаблильные тоже переводятся на webDriver. У нас хорошо была сделана абстракция от тестирующего фреймворка, поэтому проблем при миграции возникает куда меньше, чем ожидалось.
Не совсем понимаю разницу между RC и «в браузере» — у нас запускался selenium server и тест гонялись через него.
На сегодня ситуация получается такая. Есть trunk, который пытаемся держать зеленым (получается где-то процентов на 70), есть одна большая ветка с новой функциональностью, в которой работают одновременно 5+2+1+1 человек (каждая команда над своей функциональностью, но очень часто пересекаемся), все остальное делается в trunk.
У нас не совсем corporate, даже совсем не corporate. Но локальные репозитории — это действительно очень удобно, хотя мы не используем всю мощь гита (на мой взгляд). Синхронизация все равно происходит через центральный репозиторий, с которого собираются билды CI, мы пробовали синхронизироваться друг с другом, но это оказалось ненужным.
Python появился в виде IDP одного из тестировщиков — на нем начали писаться тесты для REST api. Потом оказалось, что питон отлично подходит в качестве DSL. Python мы используем в виде IronPython. Вся логика продолжает крутиться на .net.
Я свои пять часов трачу, например, на изучение F#, решение задач на project euler/top coder, написание статей на хабр. И на стэндапах так и говорю — вчера полдня читал про F#.
///
/// Mains this instance.
///
public static void Main()
www.google.by/search?q=«mains+this+instance»
И, имхо, смешивать логику и коментарии, не слишком удачная идея. Вдруг в каком-то месте придется написать что-то, относящееся именно к коду — это сразу же вылетит на UI, чего быть не должно.
nUnit — xUnit, moq — rhino — не вижу смысла менять шило на мыло.
На остальные вопросы ответов не знаю. :)
Миграция проходила достаточно гладко, сейчас новые тесты пишутся на WebDriver, старые нестаблильные тоже переводятся на webDriver. У нас хорошо была сделана абстракция от тестирующего фреймворка, поэтому проблем при миграции возникает куда меньше, чем ожидалось.
Не совсем понимаю разницу между RC и «в браузере» — у нас запускался selenium server и тест гонялись через него.