Плюсы лучших методологий юнит тестирования.
От: UberPsychoSvin  
Дата: 24.12.17 07:50
Оценка: 4 (3) +5 -2
Есть вот ИТ евангелисты которые толкают про правильные методологии тестирования. Все они уже давно на слуху: разработка через тестирование, тестирование минимальных модулей, с моканием зависимостей, по одному ассерту на тест, и т.д.

Я тут прочитал книжку про тестирование "real world" кода — "The Art Of Unit Testing". И задумался, зачем в разработке применять лучшие методологии, даёт ли это какие-то плюсы. В той книге в качестве примеров "real world" кода выступают два метода, один проверяет, что строка заканчивается на заданную подстроку, а другой складывает числа. На таких примерах всё очень красиво получается, т.к. они взаимодейтсвуют с остальным кодом через две дырки: аргументы и возвращаемое значение.

Но по моим наблюдениям, во многих проектах изрядная часть кода, взаимодействует с внешними штуками. Т.е. примерно такого вида:
public void LoadSubscriptionUpdates(long userId)
{
    var users = usersService.GetSubscriptions(userId);
    usersServiceRequests.LogServiceCall(userId, users, users.Count);
    
    var lastUpdateTime = updatesRepository.GetLatestUpdateTime();
    var now = timeService.UtcNow;
    
    var updates = usersService.GetUpdates(users.Emails, lastUpdateTime, now);
    usersServiceRequests.LogServiceCall(users.Emails, updates.Count, lastUpdateTime.ToUnixTimeStamp());
    
    var updatesDal = _dataConverter.ToDal(users, updates, lastUpdateTime, now);
    updatesRepository.Add(userId, updatesDal);
}


Если это дело писать через бест практикс:
  TDD c RGR
перевод: перед тем как писать код, пишем тест который будет фэйлиться.

  OAPT
перевод: в каждом тесте один ассерт.

  Damp over Dry
перевод: тесты не шарят общий код.


То в процессе написания рождается такая портянка тестов

[Fact("Should call GetSubscriptions")]
public void ShouldCallGetSubscriptions()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {});
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    usersServiceMock.Verify(s => s.GetSubscriptions(74), Times.Once());
}

[Fact("Should log GetSubscriptions call")]
public void ShouldLogCallGetSubscriptions()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    usersServiceRequestsMock.Verify(s => s.LogServiceCall(74, users, 10), Times.Once());
}

[Fact("Should call GetLatestUpdateTime")]
public void ShouldGetLatestUpdateTime()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    updatesRepositoryMock.Verify(s => s.GetLatestUpdateTime(), Times.Once());
}

[Fact("Should call GetUtcNow")]
public void ShouldGetUtcNow()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    timeServiceMock.Verify(s => s.UtcNow(), Times.Once());
}

[Fact("Should call GetUtcNow")]
public void ShouldGetUpdates()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    usersServiceMock.Verify(s => s.GetUpdates(new[] {"email1", "email2" }, lastUpdateTime, now), Times.Once());
}

[Fact("Should convert to dal")]
public void ShouldConvertToDal()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    dataConverterMock.Verify(s => s.ToDal(users, updates, lastUpdateTime, now), Times.Once());
}

[Fact("Should save to updatesRepository")]
public void ShouldSaveToupdatesRepository()
{
    // Arrange
    usersServiceMock.Setup(s => s.GetSubscriptions(74)).Returns(new Users {Count = 10 });
    usersServiceMock.Setup(s => s.GetUpdates(It.IsAny(), It.IsAny(), It.IsAny()).Returns(new Updates {});
    
    // Act
    usersLoader.LoadSubscriptionUpdates(74);
    
    // Assert
    updatesRepositoryMock.Verify(s => s.Add(userId, updatesDal), Times.Once());
}


Минусы очевидны. На 14 строк кода без логики, уже родилось 97 строк тестов, на вид не очень полезных. Перед любым изменением тестируемого метода, надо эти горы кода перелопачивать.

А в чём плюсы?
Re: Плюсы лучших методологий юнит тестирования.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.12.17 20:59
Оценка: 5 (2) +4
Здравствуйте, UberPsychoSvin, Вы писали:

UPS>Но по моим наблюдениям, во многих проектах изрядная часть кода, взаимодействует с внешними штуками. Т.е. примерно такого вида:

UPS>
UPS>public void LoadSubscriptionUpdates(long userId)
UPS>{
UPS>    var users = usersService.GetSubscriptions(userId);
UPS>    usersServiceRequests.LogServiceCall(userId, users, users.Count);
    
UPS>    var lastUpdateTime = updatesRepository.GetLatestUpdateTime();
UPS>    var now = timeService.UtcNow;
    
UPS>    var updates = usersService.GetUpdates(users.Emails, lastUpdateTime, now);
UPS>    usersServiceRequests.LogServiceCall(users.Emails, updates.Count, lastUpdateTime.ToUnixTimeStamp());
    
UPS>    var updatesDal = _dataConverter.ToDal(users, updates, lastUpdateTime, now);
UPS>    updatesRepository.Add(userId, updatesDal);
UPS>}
UPS>


Здесь какой то бред написан. Я бы сделал чтото навроде:

public Updates GetSubscriptionUpdates(User user, Time now) 
// а нехрен таскать по id все подряд. 
// Время всегда тащится сверху и не надо мучить попу моками.
{
    var subscriptions = usersService.GetSubscriptions(user);
    // логирование внутри GetSubscriptions
 
    var lastUpdateTime = subscriptionService.GetLatestUpdateTime(subscriptions);
    // логирование внутри GetLatestUpdateTime
    
    
    var updates = updateService.GetUpdates(subscriptions, lastUpdateTime, now); 
    // логирование внутри GetUpdates
    
    return updates;
}


+ отдельно сохранение

public void SetSubscriptionUpdate(Updates updates, Time now) {

  //var updatesDal = _dataConverter.ToDal(users, updates, lastUpdateTime, now);
  // мусор в строке выше должен быть унутре репозитория
    updatesRepository.Add(updates, now);
}


UPS>Минусы очевидны. На 14 строк кода без логики, уже родилось 97 строк тестов, на вид не очень полезных. Перед любым изменением тестируемого метода, надо эти горы кода перелопачивать.


У тебя классика — тест проверяет ровно то, что делает метод

[Fact("Should call GetSubscriptions")]


Вот такая вещь означает, что корректный результат достигнутый другим способом повалит все тесты.

UPS>А в чём плюсы?


В твоём случае одни минусы — код хрупкий.

В моем случае все немного иначе. Твои тесты ни разу не нужны. Писать нужно совсем другое.
Нужен чистый контекст, мемори DB и корректные функции задания состояния этой самой DB.
Ничего — внимание — ничего мокать не надо!
И набор тестов получаем совсем другой, не "xxx вызывает yyy", а вполне нормальную спеку

[Fact("Don't update when no subscriptions")]
[Fact("Don't update when wrong time")]
[Fact("Don't update when too early")]
[Fact("Throw exception when subscriopions are invalid")]
[Fact("Throw exception when subscriopions are invalid")]
и так далее. Тестов надо много, да, очень много!

но вот по таким тестам можно проверить спецификацию и найти, что пропущено, валидно, невалидно, устарело, актуально, неактуально и тд.

То есть, плюсы начинаются при нормальном дизайне самого кода
1. меньше время отладки — тест покажет какой именно метод отломался первым.
2. ошибки становятся известны сразу — меньше время багфикса в целом.

Соответсвенно меньше время майнтенанса — а именно эта часть наиболее затратна по усилиям и времени. То есть, экономика. Но это все при нормальном дизайне, когда решение проектируется в т.ч. под тесты, то есть, код изначально тестопригодный.

И самое главное — тесты работают только тогда, когда работа начиналась с требований. Качество есть степень соответствия требованиям.
Нет требований — нет смысла говорить про качество, потому что любое говно подойдет.
Re: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 24.12.17 08:38
Оценка: 3 (2) +4
Здравствуйте, UberPsychoSvin, Вы писали:

UPS>Если это дело писать через бест практикс:

UPS>То в процессе написания рождается такая портянка тестов

Вот и не надо им следовать.
OAPT — чушь, вызванная кривостью конкретных тестовых фреймворков (это каким же местом их надо разрабатывать, чтобы не давать к assertʼу возможность пометить конкретную проверку, хотя бы текстовой строкой). Без него уже будет 2-3-кратное сокращение кода тестов в приведённом примере, и тесты станут сопровождаемыми.
TDD — нормально работает только для задач типа "один раз написать что-то не наукоёмкое и забыть", для остальных случаев будет нарушаться, обычно — серьёзно нарушаться. Единственная гарантированно положительная черта — там, где она нужна — это административное принуждение мелких начальников хоть как-то обеспечивать качество продукта.
Про DAMP ничего плохого не скажу, но само по себе это банальность, обычно не требующая отдельного принципа (пока не начинает возводиться в абсолют и мешать остальному). Но с OAPT превращается в маразм.
The God is real, unless declared integer.
Re: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 24.12.17 17:51
Оценка: 1 (1) +3
Здравствуйте, UberPsychoSvin, Вы писали:

UPS>Есть вот ИТ евангелисты которые толкают про правильные методологии тестирования. Все они уже давно на слуху: разработка через тестирование, тестирование минимальных модулей, с моканием зависимостей, по одному ассерту на тест, и т.д.


Я ограничиваюсь интеграционными тестами, юнит тесты — только для сложных алгоритмов.
А тэорэтики пусть идут лесом.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[42]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 29.12.17 21:21
Оценка: 1 (1) +2 :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Без разницы. Максимум может быть ценна идея — а давай-ка я забабахаю ещё одно ядро юникса с такими-то фичами — но таки до сложной вещи типа Линукса это доводится командой.

CM>Как я уже писал — между hello world и проектами-монстрами типа оси есть еще очень много промежуточных этапов.
Ну дык. И внезапно программиста-одиночки уже не хватает. И внезапно требуются методологии юнит тестирования.

CM>·>market data — это по сути поток ордеров. Нужно их писать с минимальной задержкой (порядка 1мс). И давать читать, не мешая писателю писать. Данных примерно 5Tb. СУБД не справляются, пришлось писать свою имплементацию с перф-тестами и бледжеком.

CM>И даже не упомянул, есть ли там какие-то индексы или это просто "в каком порядке принял, так и записал". Это к вопросу о твоем уровне опыта.
Если бы не было индексов, это было бы не хранилище, а дамп или лог. Это к вопросу о твоем уровне опыта.

CM>В любом случае, 5 тб при современном железе — это мелочь.

Когда говорят о latency порядка миллисекунды — оно перестаёт быть мелочью. Это к вопросу о твоем уровне опыта.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[26]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 28.12.17 08:18
Оценка: +1 :)))
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Вот уж не думал, что техники тестирования

CM>Просто не люблю самоуверенных нубов.
Молодец, поставил выскочку на место!
А теперь, надеюсь, Вас, истенннного Гуру, не затруднит вернуться к теме обсуждения? Какие успешные методологии ЮТ вы рекомендуете? Х-як х-як и в продакшен или Юзер Тестирование?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.12.17 12:10
Оценка: +3
Здравствуйте, Ведмедь, Вы писали:

CM>>Я ограничиваюсь интеграционными тестами, юнит тесты — только для сложных алгоритмов.

CM>>А тэорэтики пусть идут лесом.

В>А потом месяцами релиз стабилируешь? Просто потому что с юнит тестами большинство багов не дошло прошло бы первый коммит.


Для унылого клеевого кода типа "взять шарик фарша, макнуть в сухари и плюхнуть на сковородку", коего большинство даже во вполне интересных проектах, юнит-тесты будут только наворачивать строки кода без реальной пользы. Интеграционные тесты (то есть просто функциональные, но более высокого уровня) отлавливают проблемы не хуже, а писать их всё равно надо. А рисовать юнит-тесты (неважно, с TDD или без) чтобы убедиться в том, что и глазами видно, что вызвано A и его результат применён к B... спасибо, я знаю лучше методы потратить время впустую.

А вот случаи, когда не можешь быть уверен, что вычитаешь правильно код (объективно оценивая свои способности) — нормальный программист сам нарисует тесты, чтобы убедиться, что исполняется всё правильно, включая типовые и маргинальные случаи.

Но тут к этому всему всплывают злобные административные моменты, которые всё ломают, а именно:
1. В достаточно большой разнородной команде невозможно надеяться на адекватную самооценку каждого программиста. И есть много таких, которые гарантированно попытаются читерствовать, не доработав свою часть.
Ревью от этого помогает, но не сильно.
2. Получив свои условные нормочасы (или как там считают на галерах) за код, он не захочет сам возвращаться к давно забытому коду => требуется административное насилие. А потом ещё разбираться, сколько из уже состоявшейся оплаты вычитать...

поэтому, если нет обоснованного доверия к автору, то лучше форсировать все эти требования тестов на каждом уровне, насколько вообще возможно и не покрывается другими мерами (вроде ревью).
The God is real, unless declared integer.
Re[38]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 29.12.17 17:33
Оценка: +2 :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Но ты вроде сказал, что работать надо в одиночку, иначе нуб.

CM>Если ты можешь работать в одиночку, то ты не нуб. Делать это всегда необязательно.
CM>Ну а если не можешь, то, естественно, нуб.
И что в этом сложного? Так и работал студентом, да в начале карьеры. Программа, которую может написать человек в одиночку — сложно назвать сложной, хотя в мире могут быть единичные случаи.
Работать в команде — сложнее.

CM>·>Я пользуюсь публично известными терминами. Если ты не их знаешь — погугли, копипастить я это не буду. Если ты не умеешь пользоваться гуглом, то могу дать уроки Пользователя ПК. Дорого.

CM>Нет, ты просто мутишь воду. Никаких деталей я так и не увидел.
А какие детали ты спрашивал?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[40]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 29.12.17 18:43
Оценка: 1 (1) :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Программа, которую может написать человек в одиночку — сложно назвать сложной, хотя в мире могут быть единичные случаи.

CM>"Программа, которую может написать нуб в одиночку". Небольшая поправка.
Без разницы. Максимум может быть ценна идея — а давай-ка я забабахаю ещё одно ядро юникса с такими-то фичами — но таки до сложной вещи типа Линукса это доводится командой.

CM>·>А какие детали ты спрашивал?

CM>Ну начнем с того, что это тебе следовало начать с деталей, а не с надувания щек.
CM>И во вторых — так что и где там сохраняется в твоем модуле?
market data — это по сути поток ордеров. Нужно их писать с минимальной задержкой (порядка 1мс). И давать читать, не мешая писателю писать. Данных примерно 5Tb. СУБД не справляются, пришлось писать свою имплементацию с перф-тестами и бледжеком.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 27.12.17 20:47
Оценка: :))
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Т.е. у твоей проги нет пользователей которые хоть иногда ошибаются? Но это значит, что у тебя просто нет пользователей. Охотно верю, тогда да, тесты тебе не нужны.

CM>Это всё очень интересно, но не имеет никакого отношения к ошибкам в ТЗ.
Ошибки в ТЗ это вообще не проблема при использовании тестов. Тот же подход как и в любом живом проекте с постоянно меняющимися требованиями.

Тут ведь как. Приходит заказчик и говорит — вот тут у тебя прога выдаёт 24, а должно быть 42. Ты говоришь — фигня, ща поглядим. Заглядываешь в тесты и находишь где оно выдаёт 24. По тесту смотришь на ссылку в пункт ТЗ. И отвечаешь — в пункте ТЗ 3.14.15 у вас написано, так и сяк, а значит ответ 24. Заказчик либо чешет репу и говорит, "ой, да! 24 это правильно" (тогда идём дальше читать рсдн) или "ой, блин в ТЗ — ошибка". Ты правишь тест чтобы он ожидал 42 и исправляешь код, чтобы этот тест стал проходить. После этого прогоняешь все остальные тесты и находишь, что ещё в паре мест попадало. И говоришь заказчику, что выдавать 42 мы не можем, т.к. это будет противоречить пункту ТЗ 2.71.82. И продолжаете обсуждение, пока все тесты опять не станут зелёными.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[18]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 27.12.17 22:29
Оценка: -1 :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>MTF for FX

CM>Я должен еще больше впечатлиться от обилия сокращений?
https://www.google.co.uk/search?q=MTF+for+FX
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[29]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 28.12.17 21:16
Оценка: +1 :)
Здравствуйте, ·, Вы писали:

·>Получается, что опыта участия в проекте, более сложного "мало-мальски сложной программы" нет.


Логика на уровне "да какой ты пацан, если ты не куришь"
Опыть разработки сложных программы у меня есть, и его много. Что касается юнит-тестов, то они имеют смысл только в слабо типизированных недо-языках, и/или при разработке силами большого отряда специально обученных макак.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[24]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 29.12.17 10:08
Оценка: +1 :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Ты действительно думаешь, что не написав самостоятельно ни одной мало-мальски сложной программы, можешь вообще называться программистом?


Ну во первых я уверен, что 'Hello world' писали все. Подпадает под критерий "мало-мальски сложной программы", только многие не считают это фактом, заслуживающим упоминания. Во вторых я так же уверен в том, что сколько-нибудь сложные проекты делаются коллективами и выделить личный вклад... канечна можно, но ет требует глубокого погружения контекст проекта. К примеру вот на моем крайнем проекте, на сотню человеколет, я подрабатывал рисовальщиком квадратиков и стрелочек. Какой мой вклад в этот проект — несколько десятков картинок?
Re[43]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 30.12.17 02:44
Оценка: :))
Здравствуйте, ·, Вы писали:

·>Ну дык. И внезапно программиста-одиночки уже не хватает. И внезапно требуются методологии юнит тестирования.


Не внезапно. Одного не хватает только тогда, когда тебе нужно писать что-то совсем монструозное.

·>Если бы не было индексов, это было бы не хранилище, а дамп или лог. Это к вопросу о твоем уровне опыта.


Совершенно точно не моем. Нубу хватит ума и лог назвать хранилищем

·>Когда говорят о latency порядка миллисекунды — оно перестаёт быть мелочью. Это к вопросу о твоем уровне опыта.


1e-8 секунд или около того. Примерно столько времени требуется, чтобы поместить данные в асинхронную очередь. Или там есть еще какие-то дополнительные требования, о которых ты забыл рассказать?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[50]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 04.01.18 18:32
Оценка: +1 :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Я так тебя понял, что ты предложил вначале помещать быстро в некую очередь (точнее буфер), а потом "много блоков" скидывать в файл, т.к. "быстрее" (ты так и не ответил что это значит).

CM>Быстрее и в плане latency, и в плане throughput.
Писать большими блоками не может быть лучше в плане latency.

CM>·>Сколько именно и почему?

CM>Почему бы тебе не ознакомиться с теорией, для начала?
Ну т.е. не знаешь.

CM>·>В буфере нет индексов. И веселуха начнётся при многопоточном доступе.

CM>В кэше будет всё, что ты сделаешь.
Т.е. "1e-8 секунд ... поместить данные в асинхронную очередь" у тебя ВНЕЗАПНО превратилось в кеш с блекждеком синхронизацией и индексами. Понятно откуда у тебя "ошибки в ТЗ".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[51]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 20:27
Оценка: -2
Здравствуйте, itslave, Вы писали:

I>Понятно. Трололо окончательно детектед.


Ага. Я бы даже сказал, self-detected.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[32]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.01.18 21:31
Оценка: -1 :)
Здравствуйте, CoderMonkey, Вы писали:

N>>С "просто нормальным" можно тупо не успеть по процессору.

N>>Как-то защищает очень жёсткое разделение активности по ядрам процессоров, спецдрайвера сетевух и т.п.
CM>Ну или можно просто не жлобиться на железе.

Ответ русского программиста: не просто точный, универсальный и бессмысленный, но ещё и хамский. Хорошо соответствует месту написания.

N>>Чуть не успел — потерял часть данных. Соответственно анализ уже будет с дефектами.

CM>Очередь для обработки, естественно.

То же самое.
The God is real, unless declared integer.
Re[3]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 05.01.18 13:32
Оценка: -1 :)
Здравствуйте, student__, Вы писали:

__>Или вы сразу 100% багфри код будете писать?

Он уже его и так пишет. С рождения. Интернет бойцы, они такие.
Кстате да, он сам все напишет и докажет что все эти коллеги команды — это все проедание менеджерами бюджета проекта. Он прямо так в топике и написал.
Re[7]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 05.01.18 17:51
Оценка: +1 :)
Здравствуйте, CoderMonkey, Вы писали:

I>Но все таки любопытно, процитируй пост в котором я бахвалился.

Цитаты нет — слив засчитан, балаболка.

I>>По делу я писал

CM>Покажи пример.
http://rsdn.org/forum/flame.comp/7004312.1
Автор: itslave
Дата: 26.12.17

http://rsdn.org/forum/flame.comp/7009766.1
Автор: itslave
Дата: 02.01.18

http://rsdn.org/forum/flame.comp/7007913.1
Автор: itslave
Дата: 30.12.17


I>>пока ты топик флудом не забил про свою немерянную крутизну

CM>Ну-ка ну-ка. Где, например?
http://rsdn.org/forum/flame.comp/7005777.1
Автор: CoderMonkey
Дата: 28.12.17

http://rsdn.org/forum/flame.comp/7005687.1
Автор: CoderMonkey
Дата: 28.12.17

http://rsdn.org/forum/flame.comp/7007892.1
Автор: CoderMonkey
Дата: 30.12.17

http://rsdn.org/forum/flame.comp/7007908.1
Автор: CoderMonkey
Дата: 30.12.17
Отредактировано 05.01.2018 17:52 itslave . Предыдущая версия .
Re: Плюсы лучших методологий юнит тестирования.
От: m2l  
Дата: 24.12.17 11:09
Оценка: 1 (1)
Здравствуйте, UberPsychoSvin, Вы писали:

UPS>Есть вот ИТ евангелисты которые толкают про правильные методологии тестирования. Все они уже давно на слуху: разработка через тестирование, тестирование минимальных модулей, с моканием зависимостей, по одному ассерту на тест, и т.д.

UPS>Если это дело писать через бест практикс: TDD c RGR, OAPT, Damp over Dry
Реальный мир сложней любой методологии. Они лишь пример как можно поступить в идеализированном случае. Причем для разных методологий разные идеализации.
Нужно руководствоваться здравым смыслом.

UPS>То в процессе написания рождается такая портянка тестов

UPS>Минусы очевидны. На 14 строк кода без логики, уже родилось 97 строк тестов, на вид не очень полезных.
Правильный вопрос — если ты полагаешь их бесполезными, то и не надо всё эту портянку писать.

UPS>Перед любым изменением тестируемого метода, надо эти горы кода перелопачивать.

ИМХО, одно из назначений тестов — это помощь при рефакторинге, исправлении, оптимизации и прочих изменениях, поэтому по идее, при изменении кода тесты должны либо оставаться прежними, либо меняться не очень сильно. Иначе отчасти теряется их смысл.

UPS>А в чём плюсы?

Смотри, вот ты привел кусок кода. А как ты проверяешь его работоспособность?

Можно вовсе не проверять. Скомпилилось и ладно, сразу отдал тестировщикам. Минусы это долгие итерации между тобой и тестировщиками (ты уже другим куском занялся, а они тебе кучу багов по старому), много времени на поиск причин ошибки (какие-то баги может и по памяти починишь, а что-то надо искать) и т.д. Список большинство из нас сможет продолжить.
Можно проверять, как в древности, в голове — но программы сейчас имеют большую структурную сложность, плюс всякие внешние штуки — в итоге это трудоёмко и не результативно, за исключением отдельных кусков кода.
Можно проверить по старинке — запустил программу, подал входные данные, проверил результаты. Минусы — трудоёмко на каждый чих гонять такие проверки, сложно и лень при каждом изменении проверять все варианты входных данных, для "кода который взаимодействует с внешними штуками" нужно делать тестовую среду с этими штуками. В добавок если ты гоняешь всё программу целиком — сложно оценивать работу отдельного куска кода. А если пишешь хелперы, для проверки отдельного куска — то это по сути и есть тесты, просто воспользовавшись раз, ты их выкидываешь.
Можно делать "по современному" — заменить последний вариант тестами, которые имитируют тестовую среду, гоняют проверки на всех вариантах исходных данных которые можешь придумать и делают это автоматически на каждый чих. Минус — надо писать код этих тестов.
Плюс — сокращается время и трудоёмкость поиска ошибок, не так сильно нужна тестовая среда и можно относительно безболезненно править код. Нужно подтянуть производительность или заменить библиотеку — по быстрому переписали, прогнали тесты, поправили, прогнали — сделано.

Тесты это просто один из способов проверки правильности кода. Если их плюсы перевешивают минусы — пиши. Не перевешивают — не пиши.
Единственный момент, советую сделать отдельную ветку в каком-то проекте и на практике попробовать использовать тесты к тем частям которые сейчас разрабатываются/переписываются. Тут как с системами контроля версий, важен опыт, что хранить код в vcs удобней чем не хранить.
Re: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 24.12.17 15:33
Оценка: 1 (1)
Здравствуйте, UberPsychoSvin, Вы писали:

UPS>Есть вот ИТ евангелисты которые толкают про правильные методологии тестирования. Все они уже давно на слуху: разработка через тестирование, тестирование минимальных модулей, с моканием зависимостей, по одному ассерту на тест, и т.д.

UPS>Я тут прочитал книжку про тестирование "real world" кода — "The Art Of Unit Testing". И задумался, зачем в разработке применять лучшие методологии, даёт ли это какие-то плюсы. В той книге в качестве примеров "real world" кода выступают два метода, один проверяет, что строка заканчивается на заданную подстроку, а другой складывает числа. На таких примерах всё очень красиво получается, т.к. они взаимодейтсвуют с остальным кодом через две дырки: аргументы и возвращаемое значение.
По-моему стоит смотреть на решаемую задачу в первую очередь. И тесты обычно должны соответствовать бизнес-требованиям. Обычно, в бизнес-логике есть конкретные юз-кейсы, которые и надо покрывать. Скажем, в твоём примере операция — LoadSubscriptionUpdates. И собственно это и нужно тестировать — что для данного userId вызвался updatesRepositoryAdd с нужной информацией, которая выдаётся всякими вспомогательными сервисами. Т.е. ассерт таки будет один — "updatesRepositoryMock.Verify(s => s.Add(userId, updatesDal), Times.Once());" но эти самые userId и updatesDal составлены правильно и взяты из соответсвующих моков.
Далее. Является ли LogServiceCall частью бизнес-логики без которого программа не считается работоспособной? Если да, то можно сделать второй кейс для проверки. И этот дополнительный кейс сразу говорит о том, что у тебя что-то с дизайном не то... Почему этот LogServiceCall нужно сувать везде постоянно и как не забыть это постоянно тестировать? — Отличное место для рефакторинга, найденное с помощью TDD.

А ещё я не совсем понял как у тебя тест устроен. Как у тебя в тесте проверяется, что именно значение возвращённое из timeService.UtcNow передаётся как параметр в GetUpdates?

Как я понимаю, все эти правила это следствие главного принципа — идеальное покрытие тестами должно однозначно указывать на ошибку в коде. Т.е. одна ошибка (скажем, перепутал параметры long timestamp и long userId) — должна валить ровно один тест. Но, ясное дело, как и любой идеал — недостижимо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 24.12.2017 15:54 · . Предыдущая версия . Еще …
Отредактировано 24.12.2017 15:48 · . Предыдущая версия .
Re[14]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 27.12.17 21:57
Оценка: 1 (1)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Тут ведь как. Приходит заказчик и говорит — вот тут у тебя прога выдаёт 24, а должно быть 42.

CM>Тэорэтики такие тэорэтики.
Я не теоретик... Я просто побывал в раю — работал в компании с автором книги Continuous Delivery.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Плюсы лучших методологий юнит тестирования.
От: Слава  
Дата: 24.12.17 18:04
Оценка: +1
Здравствуйте, ·, Вы писали:

·>Как я понимаю, все эти правила это следствие главного принципа — идеальное покрытие тестами должно однозначно указывать на ошибку в коде. Т.е. одна ошибка (скажем, перепутал параметры long timestamp и long userId) — должна валить ровно один тест. Но, ясное дело, как и любой идеал — недостижимо.


Конкретно в этом случае лучше сделать либо typedef Timestamp long, а потом Timestamp timestaml (или как там его в С++), либо public struct Timestamp {public long Value;} и затем полагаться на проверку типов компилятором. И и юниттесты писать не придётся.
Re[2]: Плюсы лучших методологий юнит тестирования.
От: Ведмедь Россия  
Дата: 25.12.17 11:20
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Я ограничиваюсь интеграционными тестами, юнит тесты — только для сложных алгоритмов.

CM>А тэорэтики пусть идут лесом.

А потом месяцами релиз стабилируешь? Просто потому что с юнит тестами большинство багов не дошло прошло бы первый коммит.
Да пребудет с тобой Великий Джа
Re[9]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 26.12.17 12:19
Оценка: +1
Здравствуйте, Sharov, Вы писали:

S>·>Ну потому что они "слишком большие". Юнит-тестов как правило на порядок-два больше чем интеграционных, и при этом выполняются они все на порядок-два быстрее.

S>Я не очень понял, чем юнит-тестирование с фс отличается от интграционных? По времени так точно тоже саме.
В ЮТ ты мокаешь фс и тестируешь свой модуль. В ИТ ты работаешь непосредственно с фс.

S>·>Во-во. А юнит-тесты по-хорошему обычно запускаются из IDE, ещё до коммита, а не только где-то как-то в специально настроенном окружении. Т.е. юнит-тестом я смогу протестировать/подебажить как мой модуль заработает в условиях нехватки прав и уверенно отдать тестеру/девопу, который потом воспроизведёт это в боевом окружении.

S>И как из IDE можно проверить косяки с правами доступа для опеределнного пользователя? Сидеть под его учеткой все время?
В ЮТ ты описываешь реакцию твоего модуля, например, на то, что "openFile" кинет AccessDeniedException подготавливая мок фс соответствующим образом. Поэтому этот тест ты можешь выполнить где угодно как угодно без всяких учёток. А в ИТ тебе надо создать соответсвующее окружение с учётками и т.п. чтобы убедиться, что openFile действительно кидает AccessDeniedException в таких условиях.

Чуть подробнее пример. Допустим ты пишешь модуль для чтения конфига. Нужно поискать файл с нужным именем в домашнем каталоге, если файла там нет, то нужно поискать в каталоге /etc, и если и там нет, то взять дефолтный из каталога приложения. И тут много вещей может пойти не так — имя такое есть, но это не файл, а каталог, или файл есть, но доступа нет. Или доступ есть, но файл залочен другим процессом, или файл есть, но содержимое не такое какое надо. И в каждом случае в зависимости от того, где этот файл и что пошло не так- нужно разные действия совершать — пробовать другой файл, писать логи, кидать исключения и т.п. С помощью ЮТ ты можешь легко воспроизвести различные комбинации, а их запросто может перевалить за пару десятков. Правильный ЮТ обычно выполняется за несколько миллисекунд из IDE, ещё до коммита. Если же пытаться воспроизводить это с помощью настоящей фс с разными пользователями — задолбаешься. Особенно, если разрабатываешь под Виндой, а прогу пишешь для линуха или наоборот.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 26.12.17 16:11
Оценка: +1
Здравствуйте, UberPsychoSvin, Вы писали:

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

UPS>Вот по поводу тестов файловой системы тут напрашивается умный стаб, который ведёт себя в точности так же, как ведёт себя реальная файловая система. Типа как у ORM фремйворков есть in memory database.

"Умный" стаб не нужен. Достаточно примитивных моков, по одному на сценарий.

UPS>Жалко в C# работа с FS по старинке, через статические методы.

Дык врапир делается элементарно, Буквально каждый метод в отдельности заврапать. А потом мочится в тестах элементарно. Вот с linq — да, беда, нормально замокать сложно.
Re[6]: Плюсы лучших методологий юнит тестирования.
От: Ведмедь Россия  
Дата: 27.12.17 09:05
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Здравствуйте, Ведмедь, Вы писали:


В>>При чем тут ошибки понимания ТЗ и юнит тесты? До ошибок понимания ТХ надо еще систему поднять с учетом регресса. А вот регресс проверить юнит тесты помогут на самых ранних этапах.


CM>Толку тебе, что у тебя проходят все тесты и нет регресса, если прога делает совсем не то, что должна?


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

В>>Чисто интереса ради, сколько тестов в вашей тестовой модели? Сколько из них автоматических?


CM>Плохой вопрос. Ты даже не спросил, какова величина проги.


Очень хороший вопрос, потому по нему можно судить о сложности системы и о зрелости процесса.
Да пребудет с тобой Великий Джа
Re[8]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 27.12.17 17:22
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

В>>"ТО что должна" включает в том числе и то что делала раньше (привет регрессу). А юнит тесты показывают на самом раннем этапе, что система видеть себя так как ожидалось.

CM>То же, что и делала раньше. Но не то, что должна. Но кого волнуют такие мелочи?
А как ты докажешь, что "не то, что должна", а не, например, у юзера руки кривые? При наличии тестов — просто добавишь ещё один или модифицируешь существующий в соответствии с ожиданиями и увидишь, что он проваливается.

В>>Очень хороший вопрос, потому по нему можно судить о сложности системы и о зрелости процесса.

CM>Идиотский вопрос. Примерно настолько же идиотский, как та идея советских времен измерять производительность перевозчика в тонно-километрах.
Примерно таки можно судить.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 27.12.17 19:37
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:
CM>·>А как ты докажешь, что "не то, что должна", а не, например, у юзера руки кривые?
CM>Если юзер не может использовать твою прогу для решения своей задачи, то руки кривые не у него, а у тебя.
Т.е. у твоей проги нет пользователей которые хоть иногда ошибаются? Но это значит, что у тебя просто нет пользователей. Охотно верю, тогда да, тесты тебе не нужны.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[13]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 27.12.17 21:51
Оценка: -1
Здравствуйте, ·, Вы писали:

·>Тут ведь как. Приходит заказчик и говорит — вот тут у тебя прога выдаёт 24, а должно быть 42.


Тэорэтики такие тэорэтики.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[20]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 27.12.17 23:40
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·> https://www.google.co.uk/search?q=MTF+for+FX

CM>Ну это вообще не ответ. Что конкретно ты лично написал? Всю торговую систему в одиночку?
Ну нет, конечно. Во-первых, там у нас pair programming был. Во-вторых, как ты себе представляешь работу в одиночку в такой компании? В-третьих, причём тут вообще я?
Но если так интересно, одна из запомнившихся задач — переписал модуль хранения market data, для улучшения перформанса.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[22]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 27.12.17 23:52
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Ну нет, конечно. Во-первых, там у нас pair programming был. Во-вторых, как ты себе представляешь работу в одиночку в такой компании? В-третьих, причём тут вообще я?

CM>Вопрос был — что ты написал?
И какое отношение это имеет к сабжу?

CM>·>Но если так интересно, одна из запомнившихся задач — переписал модуль хранения market data, для улучшения перформанса.

CM>То есть, ни одной серьезной задачи ты никогда в жизни не решал.
Твоё мнение очень важно для меня, спасибо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[23]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 28.12.17 00:00
Оценка: -1
Здравствуйте, ·, Вы писали:

·>Твоё мнение очень важно для меня, спасибо.


Это не мнение, это факт. Если факты для тебя не важны — тем хуже для тебя.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[24]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 28.12.17 00:25
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:
CM>·>Твоё мнение очень важно для меня, спасибо.
CM>Это не мнение, это факт. Если факты для тебя не важны — тем хуже для тебя.
Вот уж не думал, что техники тестирования кода может такое жжение вызвать, не политика же, вроде. Но ты не расстраивайся, с опытом научишься, не бином Ньютона.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[22]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 28.12.17 07:20
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Вопрос был — что ты написал?


Детский сад, ей богу.
Re[23]: Плюсы лучших методологий юнит тестирования.
От: Ведмедь Россия  
Дата: 28.12.17 09:27
Оценка: :)
Здравствуйте, itslave, Вы писали:

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


CM>>Вопрос был — что ты написал?


I>Детский сад, ей богу.


Зато ответ на вопрос "сколько тестов" был "плохой вопрос"
Да пребудет с тобой Великий Джа
Re[2]: Плюсы лучших методологий юнит тестирования.
От: landerhigh Пират  
Дата: 28.12.17 12:05
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>И самое главное — тесты работают только тогда, когда работа начиналась с требований. Качество есть степень соответствия требованиям.

I>Нет требований — нет смысла говорить про качество, потому что любое говно подойдет.

ППКС.

Самое главное — в случае ТС тесты сработали как надо. То, что потребовалась их дикая портянка, чтобы покрыть код, который ничего не делает, прямо указывает на то, что с кодом что-то не так.
Правильный код тестируется легко и удобно.
www.blinnov.com
Re[23]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 28.12.17 20:36
Оценка: :)
Здравствуйте, itslave, Вы писали:

I>Детский сад, ей богу.


Ты действительно думаешь, что не написав самостоятельно ни одной мало-мальски сложной программы, можешь вообще называться программистом?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[28]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 28.12.17 21:07
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Какие успешные методологии ЮТ вы рекомендуете? Х-як х-як и в продакшен или Юзер Тестирование?

CM>Я уже писал, в самом начале ветки. Это к вопросу о внимании и attention span-е.
Т.е. вообще не ЮТ не используешь и рекомендуешь всем без оценки применимости рекомендации. Получается, что опыта участия в проекте, более сложного "мало-мальски сложной программы" нет.
У нас ИТ отрабатывают за 30мин на кластере из ~100 компов. Без ЮТ (которые работают за 3мин на машине разработчика) вообще делать нечего.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 28.12.17 22:44
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Получается, что опыта участия в проекте, более сложного "мало-мальски сложной программы" нет.

CM>Логика на уровне "да какой ты пацан, если ты не куришь"
А что ты там такое куришь?

CM>Опыть разработки сложных программы у меня есть, и его много. Что касается юнит-тестов, то они имеют смысл только в слабо типизированных недо-языках, и/или при разработке силами большого отряда специально обученных макак.

Как я понял ты это всё в одиночку разрабатывал, иначе не мужик. Сложная программа это не та программа, которую тебе было сложно написать, а прибыльный проект с затратами порядка хотя бы 100-1000 человеко-лет. Ты в Древнем Риме родился или в Древнем Египте?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 29.12.17 01:07
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Как я понял ты это всё в одиночку разрабатывал, иначе не мужик.

CM>Не всегда,
Ужас. И как? Больно было?

CM>Так что я знаю, на что способен — в отличие от тебя с твоим "модулем для сохранения данных в таблице"

Сохранение FX market data в таблице? СУБД имеешь в виду?

CM>·>с затратами порядка хотя бы 100-1000 человеко-лет.

CM>100-1000 макако-лет — это вообще ничего не говорит.
А что говорит?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[26]: Плюсы лучших методологий юнит тестирования.
От: Sharov Россия  
Дата: 29.12.17 16:50
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Как ты сам озвучил — хорошие маркетологи, а не программисты.


Критерий будет? Мне лично кажется, что это круто, когда миллионы людей пользуются твоим кодом, пусть даже не супер-пупер сложным. Т.е. что-то от себя вложил, пусть и не самое сложное. И для меня это тоже хороший программист.

Могу для затравки критерия предложить такое понятие как польза обществу. Для этого не обязательно заниматься рокетсайенсом.
Кодом людям нужно помогать!
Re[34]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 29.12.17 17:00
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Ужас. И как? Больно было?

CM>Тебе должно быть виднее, как это бывает
Ты только что написал, что с тобой так же было. Путаешься в показаниях?

CM>·>Сохранение FX market data в таблице? СУБД имеешь в виду?

CM>Ну откуда я знаю, где там у тебя что хранилось? Раз скрываешь — значит, самому стыдно.
Т.е. нифига не знаешь, но выводы сделать готов.

CM>·>А что говорит?

CM>Описание функционала.
В смысле ТЗ привести, и чтобы как ты любишь, с ошибками?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Плюсы лучших методологий юнит тестирования.
От: Sharov Россия  
Дата: 29.12.17 17:14
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Сложность решенной задачи.


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


CM>Круто, но это маркетинг, а не программирование.


И то и другое.
Кодом людям нужно помогать!
Re[29]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 17:18
Оценка: :)
Здравствуйте, Sharov, Вы писали:

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


Сложно раскрутить, поскольку процесс это нелогичный и сильно зависит от случайности. Разработать — намного проще.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[36]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 29.12.17 17:20
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Ты только что написал, что с тобой так же было. Путаешься в показаниях?

CM>Со мной было так, что я работал в некоторых проектах один и в некоторых в команде. А что было у тебя, от чего должно быть больно — это только тебе известно.
Но ты вроде сказал, что работать надо в одиночку, иначе нуб.

CM>·>Т.е. нифига не знаешь, но выводы сделать готов.

CM>Попытки замутить воду с твоей стороны — тоже неплохое основание для выводов.
Я пользуюсь публично известными терминами. Если ты не их знаешь — погугли, копипастить я это не буду. Если ты не умеешь пользоваться гуглом, то могу дать уроки Пользователя ПК. Дорого.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[40]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 29.12.17 21:14
Оценка: +1
Здравствуйте, Sharov, Вы писали:

S>·>И что в этом сложного? Так и работал студентом, да в начале карьеры. Программа, которую может написать человек в одиночку — сложно назвать сложной, хотя в мире могут быть единичные случаи.

S>·>Работать в команде — сложнее.
S>Справедливости ради, всяческие движки для чего-нибудь, требующие активно использовать соотв. мат. аппарат. мало кто может сделать. Здесь есть одиночки, и это действительно бывает трудно. Особенно понять код.
Это же единичные случаи. Да и тут можно о терминах поспорить — ибо в такой программе сложность и ценность не в программировании, а в матаппарате.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[26]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 30.12.17 00:33
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>А мне почему-то кажется, что между hello world и монстром типа линукса есть немало промежуточных этапов.

И большинство из этих "этапов" — работа в коллективе. Тот же линукс сегодня — это банальная командная разработка.
Re[40]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 30.12.17 00:37
Оценка: :)
Здравствуйте, Sharov, Вы писали:

S>Справедливости ради, всяческие движки для чего-нибудь, тва.ребующие активно использовать соотв. мат. аппарат. мало кто может сделать. Здесь есть одиночки, и это действительно бывает трудно. Особенно понять код.

Ну опять таки, одиночки могут разве что ядро написать. А довести идею до готового продукта — ет снова коллективная работа.
Re[28]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 30.12.17 04:30
Оценка: +1
Здравствуйте, CoderMonkey, Вы писали:

CM>Как правило, просто потому, что менеджер с маленькой командой — это просто полный лох в глазах других менеджеров

Да возьми любой успешный опенсорс продукт — везде команды.
Re[44]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 30.12.17 04:46
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Не внезапно. Одного не хватает только тогда, когда тебе нужно писать что-то совсем монструозное.


Это вброс, или ты ничего больше hello world не писал никогда?
Re[30]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 30.12.17 06:00
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Опенсорс пилят обычно в качестве хобби (то есть времени на него очень мало), либо это самый обычный проект с манагерами, только опен сорс.


Угу, куда ни посмотри — всюду злые манагеры, которые спят и видят ка кнарастить себе команды. Не дают развернуться гениям-одиночкам, скорее всего самоучкам.
Re[6]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 30.12.17 07:45
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

N>>Ну против таких ситуаций есть метод требовать написание тестов не автором кода, а именно QC сотрудниками.

N>>Jef239@habr настойчиво рекомендовал такой вариант ещё и потому, что тестеры значительно дешевле.
CM>Всё равно фуфло, потому что 1) ошибки могут быть непосредственно в ТЗ

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

CM> 2) вероятность ошибок в тестах при таком подходе становится еще выше.


Чего это?

CM> А еще есть разнообразные недетерминированные ошибки, против которых юнит-тесты тоже совершенно бесполезны.


Так я не отрицаю важность функциональных тестов более высокого уровня. Но против плавающих ошибок и они не очень полезны, если дополнительно не снабжаются методиками поиска именно таких ошибок.
The God is real, unless declared integer.
Re[44]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 30.12.17 10:36
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Ну дык. И внезапно программиста-одиночки уже не хватает. И внезапно требуются методологии юнит тестирования.

CM>Не внезапно. Одного не хватает только тогда, когда тебе нужно писать что-то совсем монструозное.
Вопросов о твоем уровне опыта больше нет.

CM>·>Если бы не было индексов, это было бы не хранилище, а дамп или лог. Это к вопросу о твоем уровне опыта.

CM>Совершенно точно не моем. Нубу хватит ума и лог назвать хранилищем
Ага-ага. Споришь со своими домыслами?

CM>·>Когда говорят о latency порядка миллисекунды — оно перестаёт быть мелочью. Это к вопросу о твоем уровне опыта.

CM>1e-8 секунд или около того. Примерно столько времени требуется, чтобы поместить данные в асинхронную очередь. Или там есть еще какие-то дополнительные требования, о которых ты забыл рассказать?
Какая ещё очередь в таких условиях? Буфер, конечно. Ну поместили в буфер, а дальше что? Данные-то всё прут и прут. Или у тебя буфер размером 5Tb? И как из буфера читатели будут читать?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 02.01.18 12:16
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Разделение есть. Интеграционные тесты работают на уровне всей системы — по определению. И тестируют работу системы в связке со всем окружением.

C>Юнит тесты никак не могут являться функциональными тестами, так как не работают в реальном окружении.
Тут уже по-моему вопрос терминологии. У нас были такие термины:
Юнит-тесты — их много, они сверхбыстрые, запускаешь их всех ещё перед коммитом. Тестируют небольшой кусок кода (обычно один класс, бывает чуть больше).
Интеграционные тесты — их меньше, тестируют взаимодействие кода с другими компонентами. Например, DAO <-> dbms, FIX-gateway <-> FIX-клиент, сокеты, файлы, етс. Их меньше, работают долго, т.к. требуют, например, запустить какой-нибудь mysql, залить тестовыми данными и т.п.
Приёмочные тесты (acceptance tests) — запуск системы практически целиком и тестирование полных сценариев, соответсвующих бизнес-требованиям. Работают пол часа на кластере из сотни компов, на машине разработчика их все запустить нереально.
Т.е. интеграционные тесты в идеале тестируют интеграцию двух компонент, а приёмочные — тестируют всю систему целиком.


Это одна ось. Другая ось — функциональные тесты/нефункциональные. Это соответсвует функциональным требованиям/нефункциональным. Т.е. "Система должна продать слона" — это функциональное требование, А "система должна способна продавать до 1000 слонов в секунду даже при падении одного из серверов" — это уже нефункциональное. Значит, всякие перформанс-тесты, тесты recovery, бэкапов, staging, миграции — это всё нефункциональные. Они, как правило, интеграционные. Но ничто не мешает сделать небольшой юнит-тест для измерения перформанса некоего юнита.

Ещё у нас были так называемые conformance tests, которые проверяют 3-rd party системы, что они работают так, как мы ожидаем.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[48]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 04.01.18 08:45
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Выкинь свой телепатор, он не работает.

Извини, но в этом топике ты отметился исключительно забавным понторезанием о своей невменяемой крутости в непонимании элементарных инженерных практик. Никакой конкретики, никакого конструктива. Либо же это троллинг из серии "настолько толсто что уже тонко".
Re[49]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 16:58
Оценка: -1
Здравствуйте, itslave, Вы писали:

I>Извини, но в этом топике ты отметился исключительно забавным понторезанием о своей невменяемой крутости


Не в большей степени, че ты.

I>в непонимании элементарных инженерных практик.


Юнит тесты — это всего лишь вопрос религии, и никакими "элементарными инженерными практиками" здесь и не пахнет.

I>Никакой конкретики, никакого конструктива.


Враньё. Меньше пиши, лучше читай.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[48]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 04.01.18 17:46
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Что значит "быстрее"? throughput или latency? Если файловая операция будет больше нескольких миллисекунд, то входной сетевой буфер переполнится в самый неподходящий момент (пик нагрузки) и придётся делать redeliver — что только усугубляет ситуацию.

CM>Вот так за несколько миллисекунд и сразу переполнится? Путаешься в показаниях.
Я так тебя понял, что ты предложил вначале помещать быстро в некую очередь (точнее буфер), а потом "много блоков" скидывать в файл, т.к. "быстрее" (ты так и не ответил что это значит). Но если ты тратишь >10мс на запись в файл "по много блоков", то сетевой буфер может переполниться во время пика.
И вообще, что значит "много блоков"? Сколько именно и почему?

CM>·>Блок в буфере или в файле? Ты путаешься уже.

CM>Сначала в одном, потом в другом. Можно начинать одновременно, чтобы было быстрее. Кэш обычно делается именно так
В буфере нет индексов. И веселуха начнётся при многопоточном доступе.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[50]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 04.01.18 20:25
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>Враньё. Меньше пиши, лучше читай.

Понятно. Трололо окончательно детектед.
Re[26]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.01.18 20:41
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

N>>Полная подписка будет выше 20Gbit/s. И так безжалостно урезаем.

CM>То есть, на самом деле 2.5 гигабайта в секунду. Это уже не так мелко, но всё равно легко укладывается в RAID, и даже можно обойтись без кластера. А шуму то было

Ответ в твоём же стиле: шум был у тебя в голове.
А данные надо не просто записать на диск, а переработать и проиндексировать.
The God is real, unless declared integer.
Re[28]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.01.18 20:54
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

N>>А данные надо не просто записать на диск, а переработать и проиндексировать.

CM>Это уже больше похоже на нормальную задачу

Ну я вообще-то сказал об этом с самого начала. Даже с учётом относительно лёгкой переработки тут уже есть над чем хорошо подумать.

Для дополнительного устрашения сообщу, что данные поступают обычно по UDP multicast, перезапросы невозможны. На любые вопросы по поводу этого поставщик фыркает и цедит сквозь зубы, что солидные пацаны возле биржи — не экономят на железе
The God is real, unless declared integer.
Re[12]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.01.18 21:22
Оценка: -1
Здравствуйте, CoderMonkey, Вы писали:

N>>Не буду вступать в спор по этому поводу, но BDUF и не предлагался. То, что ты не понимаешь разницы, очень показательно.

CM>Предусмотреть все возможные ошибки, неточности и противоречия еще при планировании и написании ТЗ — это как раз чистейший BDUF. А он не работает.

Вот именно что ты путаешь чисто внутренние противоречия ТЗ и его адекватность внешней задаче.

N>>Это не помешает написать тесты согласно текущему ТЗ.

CM>Полезность которых будет равна нулю из-за ошибок на верхнем уровне, а потом их придется еще и переписывать.

Да. Но в дальнем плане не отличается от изменения задачи из-за неизбежного изменения внешних условий.

N>>Ссылки на "[практически] никто не использует" — в студию.

CM>Не, логика так не работает. Это ты доказывай, что его на самом деле используют.

Именно так и работает. Я просто его упомянул, а ты сказал, что его не используют. Доказывай.
The God is real, unless declared integer.
Re[5]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 05.01.18 17:36
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

CM>На себя посмотри, родной. Вообще ни слова по делу не написал, только зубоскалишь и бахвалишься.

По делу я писал, пока ты топик флудом не забил про свою немерянную крутизну, в отличии от остальных участников срача. Кстате, не указан ни единого проекта, который ты "сделал сам". Но все таки любопытно, процитируй пост в котором я бахвалился.
Re[9]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 05.01.18 18:15
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:
Трололо, такое трололо...
Re[36]: Плюсы лучших методологий юнит тестирования.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.01.18 07:27
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>А что, очередь ускорит процессор?


CM>Нет, но она 1) не будет подолгу блокировать коллбеки от сетевого стека, что уменьшает вероятность потери данных 2) позволит передавать часть данных для обработки на другой компьютер, в любой удобной тебе форме


То есть, под словом "очередь" ты подразумеваешь какую то особую распределенную архитектуру обработки данных. Вариантов такой архитектуры вагон и маленькая тележка и у всех есть особенности, достоинства и недостатки. Как понять, какой именно вариант нужен ?
Re: Плюсы лучших методологий юнит тестирования.
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 24.12.17 13:37
Оценка:
Здравствуйте, UberPsychoSvin, Вы писали:

UPS>Минусы очевидны.

UPS>А в чём плюсы?

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

Мало того, что сторонники TDD описывающие их в книгах приверженцы Agile, так они ещё и наперёд продумывают возможные изменения. Здесь же в чём прикол, как объясняют в книжках, потом вы тесты для программы не напишите, так пишите их до написания кода. Именно до, а не сразу после написания. То есть программист ещё не начал писать работающий код, а тест уже готов и попробуй в него уложиться.

В итоге основную пользу будет извлекать высокоуровневый программист, чуть ли не ясновидящий. Обычный же, который делает как может по крайне мере в начале получит жёсткий дебаф. Чтобы его снять, нужно юзать TDD продолжительное время, и то, кто-то научится, а кто-то нет, а кто-то даже не начнёт.

Так что здесь вопрос вот в чём:
1. Нужно ли юнит-тестирование?
2. И если всё же нужно, то когда это делать, до написания кода или после?

А если не нужно, тогда:
Re[2]: Плюсы лучших методологий юнит тестирования.
От: UberPsychoSvin  
Дата: 24.12.17 16:52
Оценка:
Здравствуйте, ·, Вы писали:
·>А ещё я не совсем понял как у тебя тест устроен. Как у тебя в тесте проверяется, что именно значение возвращённое из timeService.UtcNow передаётся как параметр в GetUpdates?
В Moq в Verify достаточно передать это время как параметр. И тогда он засчитает срабатывание метода, только если он будет вызван с таким же аргументом.

Здравствуйте, m2l, Вы писали:
m2l>Смотри, вот ты привел кусок кода. А как ты проверяешь его работоспособность?

verify'ями из примера выше я проверяю, что кусок кода работает при поведении, которое я мокаю исходя из своих ДОГАДОК, о том, как будут вести себя внешние зависимости. Будет ли работать вся фича, целиком, хрен её знает.

Вот пример.

class TaskProcessor : ITaskProcessor
{
    public void ProcessTask(Task task) // можно тестить обработку всего таска
    {
        while(!IsProcessed(task.Status)) 
        {
            task.Status = taskProcessor.ProcesTaskStatus(task);
            // чего то ещё делаем
        }
    }
}

class TaskStatusProcessor : ITaskStatusProcessor
{
    public void ProcesTaskStatus(Task task) // можно тестить обработку отдельного статуса
    {
        switch(task.Status)
        {
            // процессим конкретные статусы
        }
    }
}


Тут юнит тестами невозможно проверить, что таск вообще в принципе может запроцеситься. Проверить работоспособность я могу, если напишу интеграционный тест, в котором буду тестировать связку TaskProcessor + TaskStatusProcessor.


В целом такие мысли.

Полезнее всего тестить максимально жирными интеграционными тестами все модули относящиеся к одной фиче в связке, заменяя стабами неудобные зависимости, к примеру реальные сервисы. Стабы должны отдавать примеры реальных данных.

Получаются такие плюсы.
    Можно менять внутренние модули, из которых состоит фича без возни с тестами.
    Заодно тестируется БД.
    Заодно тестируется многопоточное поведение.
    Заодно тестируются временные аспекты. К примеру, операции по таймауту.
    Заодно тестируется конфиг.
    Не нужно делать угадайки о том, какие данные будут приходить в модули.

Правда о быстром цикле: что-то поправил, запустил тест, ещё что то поправил, запустил тест, можно забыть.
Юнит тесты можно оставить для особых мест.
Re[3]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 24.12.17 21:07
Оценка:
Здравствуйте, UberPsychoSvin, Вы писали:

UPS>·>А ещё я не совсем понял как у тебя тест устроен. Как у тебя в тесте проверяется, что именно значение возвращённое из timeService.UtcNow передаётся как параметр в GetUpdates?

UPS>В Moq в Verify достаточно передать это время как параметр. И тогда он засчитает срабатывание метода, только если он будет вызван с таким же аргументом.
Тогда ок. Значения параметров надо проверять.

m2l>>Смотри, вот ты привел кусок кода. А как ты проверяешь его работоспособность?

UPS>verify'ями из примера выше я проверяю, что кусок кода работает при поведении, которое я мокаю исходя из своих ДОГАДОК, о том, как будут вести себя внешние зависимости. Будет ли работать вся фича, целиком, хрен её знает.

UPS>Вот пример.

Тут можно юнит-тестом покрыть логику ProcessTask завершения процесса когда статус таска — "завершен".

UPS>Тут юнит тестами невозможно проверить, что таск вообще в принципе может запроцеситься.

Что логично. Ибо это никак проверить нельзя (по крайней мере я не вижу в приведённом коде такого, что это гарантирует).

UPS> Проверить работоспособность я могу, если напишу интеграционный тест, в котором буду тестировать связку TaskProcessor + TaskStatusProcessor.

А вообще говоря да, если код тривиальный, то можно и не юнит-тестить. Он покроется другими тестами.

UPS>В целом такие мысли.


UPS>Полезнее всего тестить максимально жирными интеграционными тестами все модули относящиеся к одной фиче в связке, заменяя стабами неудобные зависимости, к примеру реальные сервисы. Стабы должны отдавать примеры реальных данных.

Интеграционные тесты не заменяют юнит-тесты, а дополняют. Жирных тестов много не напишешь, или они будут работать часами/днями. А юнит-тестами можно покрывать каждую мелочь.
Например, юнит-тестами могу покрыть кучу вариантов и реакции на них — что делать когда имя файла плохое, файл уже существует, файл не доступен для чтения, файл не такого типа и т.п., а в интеграционном тесте скорее всего будет только успешный сценарий когда файл используется как надо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Плюсы лучших методологий юнит тестирования.
От: koenig  
Дата: 24.12.17 21:34
Оценка:
CM>Я ограничиваюсь интеграционными тестами, юнит тесты — только для сложных алгоритмов.
CM>А тэорэтики пусть идут лесом.

слова не junior-a, но мужа
Re[3]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 24.12.17 22:27
Оценка:
Здравствуйте, Слава, Вы писали:

С>·>Как я понимаю, все эти правила это следствие главного принципа — идеальное покрытие тестами должно однозначно указывать на ошибку в коде. Т.е. одна ошибка (скажем, перепутал параметры long timestamp и long userId) — должна валить ровно один тест. Но, ясное дело, как и любой идеал — недостижимо.

С>Конкретно в этом случае лучше сделать либо typedef Timestamp long, а потом Timestamp timestaml (или как там его в С++), либо public struct Timestamp {public long Value;} и затем полагаться на проверку типов компилятором. И и юниттесты писать не придётся.
Ну конкретно тут они оба long. Правильно это или нет — другой вопрос. А в общем случае у тебя всё равно когда-нибдуь будут timestampFrom, timestampTo, userA, userB и т.п.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 25.12.17 17:12
Оценка:
Здравствуйте, Ведмедь, Вы писали:

В>А потом месяцами релиз стабилируешь?


Неа.

В>Просто потому что с юнит тестами большинство багов не дошло прошло бы первый коммит.


Фуфло. Никакие юнит тесты ничего не гарантируют, поскольку от ошибок понимания ТЗ не спасают, и даже для более примитивных багов тоже ничего не гарантируют, поскольку сами могут содержать ошибки.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[4]: Плюсы лучших методологий юнит тестирования.
От: Sharov Россия  
Дата: 25.12.17 17:49
Оценка:
Здравствуйте, ·, Вы писали:

·>Например, юнит-тестами могу покрыть кучу вариантов и реакции на них — что делать когда имя файла плохое, файл уже существует, файл не доступен для чтения, файл не такого типа и т.п., а в интеграционном тесте скорее всего будет только успешный сценарий когда файл используется как надо.


Это же противоречит сути юнит-тестов -- мокировать окружающую среду. А в чем проблема в интеграционном тесте все эти случаи проверить в ручную подкладывая левый файлы?
Кодом людям нужно помогать!
Re[5]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 25.12.17 17:54
Оценка:
Здравствуйте, Sharov, Вы писали:

S>·>Например, юнит-тестами могу покрыть кучу вариантов и реакции на них — что делать когда имя файла плохое, файл уже существует, файл не доступен для чтения, файл не такого типа и т.п., а в интеграционном тесте скорее всего будет только успешный сценарий когда файл используется как надо.

S>Это же противоречит сути юнит-тестов -- мокировать окружающую среду.
???!!! В юнит-тестах вроде обычно мокируют всё кроме собственно тестируемого юнита.

S>А в чем проблема в интеграционном тесте все эти случаи проверить в ручную подкладывая левый файлы?

Можно, но будет заметно медленнее. И такие вещи как "прав на чтение нет" потребуют извращений с операционкой.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: Плюсы лучших методологий юнит тестирования.
От: Sharov Россия  
Дата: 25.12.17 19:23
Оценка:
Здравствуйте, ·, Вы писали:

·>???!!! В юнит-тестах вроде обычно мокируют всё кроме собственно тестируемого юнита.


В данном случае придется мокировать тестируемый юнит Берд конечно, но я не представляю себе юнит-тестов для работы с фс. Это уже не ют.

·>Можно, но будет заметно медленнее. И такие вещи как "прав на чтение нет" потребуют извращений с операционкой.


Почему медленнее? Это вообще отдельные тесты, которые такое поведение тестируют. Ну да, боевое окружение, зато по-настоящему.

·>И такие вещи как "прав на чтение нет" потребуют извращений с операционкой.


Запускать тесты из под какого-нибудь guest'а? Или специально настроить соотв. пользователя и с ним все проверять. Ну это уже из области devops.
Кодом людям нужно помогать!
Re[7]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 25.12.17 19:52
Оценка:
Здравствуйте, Sharov, Вы писали:

S>·>???!!! В юнит-тестах вроде обычно мокируют всё кроме собственно тестируемого юнита.

S>В данном случае придется мокировать тестируемый юнит Берд конечно, но я не представляю себе юнит-тестов для работы с фс. Это уже не ют.
У тебя может быть юнит поиска и чтения конфиг-файла в разных локациях, например. А все эти вариации "что могло пойти не так" могут быть вызваны в т.ч. и фс.

S>·>Можно, но будет заметно медленнее. И такие вещи как "прав на чтение нет" потребуют извращений с операционкой.

S>Почему медленнее? Это вообще отдельные тесты, которые такое поведение тестируют. Ну да, боевое окружение, зато по-настоящему.
Ну потому что они "слишком большие". Юнит-тестов как правило на порядок-два больше чем интеграционных, и при этом выполняются они все на порядок-два быстрее.

S>·>И такие вещи как "прав на чтение нет" потребуют извращений с операционкой.

S>Запускать тесты из под какого-нибудь guest'а? Или специально настроить соотв. пользователя и с ним все проверять. Ну это уже из области devops.
Во-во. А юнит-тесты по-хорошему обычно запускаются из IDE, ещё до коммита, а не только где-то как-то в специально настроенном окружении. Т.е. юнит-тестом я смогу протестировать/подебажить как мой модуль заработает в условиях нехватки прав и уверенно отдать тестеру/девопу, который потом воспроизведёт это в боевом окружении.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Плюсы лучших методологий юнит тестирования.
От: Ведмедь Россия  
Дата: 26.12.17 08:39
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>Здравствуйте, Ведмедь, Вы писали:


В>>Просто потому что с юнит тестами большинство багов не дошло прошло бы первый коммит.


CM>Фуфло. Никакие юнит тесты ничего не гарантируют, поскольку от ошибок понимания ТЗ не спасают, и даже для более примитивных багов тоже ничего не гарантируют, поскольку сами могут содержать ошибки.


При чем тут ошибки понимания ТЗ и юнит тесты? До ошибок понимания ТХ надо еще систему поднять с учетом регресса. А вот регресс проверить юнит тесты помогут на самых ранних этапах.

Чисто интереса ради, сколько тестов в вашей тестовой модели? Сколько из них автоматических?
Да пребудет с тобой Великий Джа
Re[8]: Плюсы лучших методологий юнит тестирования.
От: Sharov Россия  
Дата: 26.12.17 09:48
Оценка:
Здравствуйте, ·, Вы писали:

·>Ну потому что они "слишком большие". Юнит-тестов как правило на порядок-два больше чем интеграционных, и при этом выполняются они все на порядок-два быстрее.


Я не очень понял, чем юнит-тестирование с фс отличается от интграционных? По времени так точно тоже саме.

·>Во-во. А юнит-тесты по-хорошему обычно запускаются из IDE, ещё до коммита, а не только где-то как-то в специально настроенном окружении. Т.е. юнит-тестом я смогу протестировать/подебажить как мой модуль заработает в условиях нехватки прав и уверенно отдать тестеру/девопу, который потом воспроизведёт это в боевом окружении.


И как из IDE можно проверить косяки с правами доступа для опеределнного пользователя? Сидеть под его учеткой все время?
Кодом людям нужно помогать!
Re[10]: Плюсы лучших методологий юнит тестирования.
От: UberPsychoSvin  
Дата: 26.12.17 15:49
Оценка:
Здравствуйте, ·, Вы писали:
Вот по поводу тестов файловой системы тут напрашивается умный стаб, который ведёт себя в точности так же, как ведёт себя реальная файловая система. Типа как у ORM фремйворков есть in memory database.

Жалко в C# работа с FS по старинке, через статические методы.
Re[5]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 26.12.17 16:19
Оценка:
Здравствуйте, Ведмедь, Вы писали:

В>При чем тут ошибки понимания ТЗ и юнит тесты? До ошибок понимания ТХ надо еще систему поднять с учетом регресса. А вот регресс проверить юнит тесты помогут на самых ранних этапах.


Толку тебе, что у тебя проходят все тесты и нет регресса, если прога делает совсем не то, что должна?

В>Чисто интереса ради, сколько тестов в вашей тестовой модели? Сколько из них автоматических?


Плохой вопрос. Ты даже не спросил, какова величина проги.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[7]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 26.12.17 16:24
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Запускать тесты из под какого-нибудь guest'а? Или специально настроить соотв. пользователя и с ним все проверять. Ну это уже из области devops.


В томто и дело, что юнит тесты — environment agnostic. Все внешние зависимости мокаются/стабаются. Цель юнит тестов — проверить что бизнес логика работает "как надо" и ее никто не поломал случайно при фиксе багов-рефакторинге. Возьмем пример из стартпоста:

var lastUpdateTime = updatesRepository.GetLatestUpdateTime();
var now = timeService.UtcNow;
var updates = usersService.GetUpdates(users.Emails, lastUpdateTime, now);

Имеет смысл написать в тесты на то что
— updatesRepository.GetLatestUpdateTime() — вызывается
— timeService.UtcNow; — вызывается
— значения времени правильно передаются в usersService.GetUpdates, не перепутав местами.
В общим имеет смысл писать по тесту на каждую ветку в коде бизнес логики. И только бизнес логики. Вся инфраструктура мочится. Они пишутся пачками(тысячи юнит тестов — это элементарно в проектах на пару человеколет), очень быстро(потому что примитивные) и пачками же выкидываются при крупных рефакторингах. При этом они ранаются очень быстро, не дольше пары минут и совершенно не зависят от енва. Поэтому могут запускаться как из студии, так и перед мержем, автоматически, и перед билдом.
В отличии от них, интеграционные тесты требуют специфического енва, как правило запускаются на последних этапах CI и могут бежать несколько часов. При этом проверяют "все".
ИМХА нужны и те и эти. В проектах, в которых цена ошибки высока. Юнит тесты — для раннего обнаружения и быстрого фикса наиболее типичных ошибок и опечаток. Интеграционные — для финальной проверки всего продукта в конкретной среде окружения.
Re[4]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 26.12.17 17:06
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

В>>Просто потому что с юнит тестами большинство багов не дошло прошло бы первый коммит.

CM>Фуфло. Никакие юнит тесты ничего не гарантируют, поскольку от ошибок понимания ТЗ не спасают, и даже для более примитивных багов тоже ничего не гарантируют, поскольку сами могут содержать ошибки.

Ну против таких ситуаций есть метод требовать написание тестов не автором кода, а именно QC сотрудниками.
Jef239@habr настойчиво рекомендовал такой вариант ещё и потому, что тестеры значительно дешевле.
The God is real, unless declared integer.
Re[5]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 26.12.17 17:09
Оценка:
Здравствуйте, netch80, Вы писали:

N>Ну против таких ситуаций есть метод требовать написание тестов не автором кода, а именно QC сотрудниками.

N>Jef239@habr настойчиво рекомендовал такой вариант ещё и потому, что тестеры значительно дешевле.

Всё равно фуфло, потому что 1) ошибки могут быть непосредственно в ТЗ 2) вероятность ошибок в тестах при таком подходе становится еще выше. А еще есть разнообразные недетерминированные ошибки, против которых юнит-тесты тоже совершенно бесполезны.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[12]: Плюсы лучших методологий юнит тестирования.
От: UberPsychoSvin  
Дата: 26.12.17 18:25
Оценка:
Здравствуйте, itslave, Вы писали:
I>"Умный" стаб не нужен. Достаточно примитивных моков, по одному на сценарий.
Умный стаб нужен для интеграционных тестов. Ну типа прокидываешь в фичу, InMemoryDbContextStub, InMemoryFileSystemStub.
И всё вжуххх, и отработало моментально.
Re[11]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 26.12.17 18:52
Оценка:
Здравствуйте, UberPsychoSvin, Вы писали:

UPS>Вот по поводу тестов файловой системы тут напрашивается умный стаб, который ведёт себя в точности так же, как ведёт себя реальная файловая система. Типа как у ORM фремйворков есть in memory database.

UPS>Жалко в C# работа с FS по старинке, через статические методы.
Так это не только файловая система, а любой другой юнит. Тут и веб-сервис, и субд, и "сервис подсчёта скидки, который пишет другая команда", и "класс который должен делать что-то такое, но напишу его реализацию завтра", и т.п. Ведь юнит-тесты можно писать ещё до того, как другие юниты с которыми интегрироваться даже существуют. Т.е. интегрироваться ещё не с чем, а работающий и протестированный код уже есть.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Плюсы лучших методологий юнит тестирования.
От: Ведмедь Россия  
Дата: 27.12.17 09:12
Оценка:
Здравствуйте, netch80, Вы писали:

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


В>>>Просто потому что с юнит тестами большинство багов не дошло прошло бы первый коммит.

CM>>Фуфло. Никакие юнит тесты ничего не гарантируют, поскольку от ошибок понимания ТЗ не спасают, и даже для более примитивных багов тоже ничего не гарантируют, поскольку сами могут содержать ошибки.

N>Ну против таких ситуаций есть метод требовать написание тестов не автором кода, а именно QC сотрудниками.

N>Jef239@habr настойчиво рекомендовал такой вариант ещё и потому, что тестеры значительно дешевле.

Эм. как мне кажется тут есть путаница между функциональными автотестами и юниттестами. Функциональные автотесты должны писать как раз QA, а юнит тесты авторы кода.
Функциональные тесты по ТЗ делаются на систему как на черный ящик, юнит тесты на часть системы как на белый ящик (да еще с моками без учета окружения)
Да пребудет с тобой Великий Джа
Re[13]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 27.12.17 09:26
Оценка:
Здравствуйте, UberPsychoSvin, Вы писали:

UPS>Умный стаб нужен для интеграционных тестов. Ну типа прокидываешь в фичу, InMemoryDbContextStub, InMemoryFileSystemStub.

UPS>И всё вжуххх, и отработало моментально.
А моки/стабы в интеграционных тестах вообще убивают идею интеграционного тестирования.
Re[7]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 27.12.17 17:15
Оценка:
Здравствуйте, Ведмедь, Вы писали:

В>"ТО что должна" включает в том числе и то что делала раньше (привет регрессу). А юнит тесты показывают на самом раннем этапе, что система видеть себя так как ожидалось.


То же, что и делала раньше. Но не то, что должна. Но кого волнуют такие мелочи?

В>Очень хороший вопрос, потому по нему можно судить о сложности системы и о зрелости процесса.


Идиотский вопрос. Примерно настолько же идиотский, как та идея советских времен измерять производительность перевозчика в тонно-километрах.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[9]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 27.12.17 18:06
Оценка:
Здравствуйте, ·, Вы писали:

·>А как ты докажешь, что "не то, что должна", а не, например, у юзера руки кривые?


Если юзер не может использовать твою прогу для решения своей задачи, то руки кривые не у него, а у тебя.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[11]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 27.12.17 20:19
Оценка:
Здравствуйте, ·, Вы писали:

·>Т.е. у твоей проги нет пользователей которые хоть иногда ошибаются? Но это значит, что у тебя просто нет пользователей. Охотно верю, тогда да, тесты тебе не нужны.


Это всё очень интересно, но не имеет никакого отношения к ошибкам в ТЗ.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[15]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 27.12.17 22:19
Оценка:
Здравствуйте, ·, Вы писали:

·>Я не теоретик... Я просто побывал в раю — работал в компании с автором книги Continuous Delivery.


Я просто невероятно впечатлен. И что написал?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[16]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 27.12.17 22:25
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Я не теоретик... Я просто побывал в раю — работал в компании с автором книги Continuous Delivery.

CM>Я просто невероятно впечатлен. И что написал?
MTF for FX
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[17]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 27.12.17 22:27
Оценка:
Здравствуйте, ·, Вы писали:

·>MTF for FX


Я должен еще больше впечатлиться от обилия сокращений?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[19]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 27.12.17 23:34
Оценка:
Здравствуйте, ·, Вы писали:

·> https://www.google.co.uk/search?q=MTF+for+FX


Ну это вообще не ответ. Что конкретно ты лично написал? Всю торговую систему в одиночку?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[21]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 27.12.17 23:44
Оценка:
Здравствуйте, ·, Вы писали:

·>Ну нет, конечно. Во-первых, там у нас pair programming был. Во-вторых, как ты себе представляешь работу в одиночку в такой компании? В-третьих, причём тут вообще я?


Вопрос был — что ты написал?

·>Но если так интересно, одна из запомнившихся задач — переписал модуль хранения market data, для улучшения перформанса.


То есть, ни одной серьезной задачи ты никогда в жизни не решал.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[25]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 28.12.17 00:59
Оценка:
Здравствуйте, ·, Вы писали:

·>Вот уж не думал, что техники тестирования


Просто не люблю самоуверенных нубов.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[27]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 28.12.17 20:36
Оценка:
Здравствуйте, ·, Вы писали:

·>Какие успешные методологии ЮТ вы рекомендуете? Х-як х-як и в продакшен или Юзер Тестирование?


Я уже писал, в самом начале ветки. Это к вопросу о внимании и attention span-е.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[31]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 28.12.17 23:28
Оценка:
Здравствуйте, ·, Вы писали:

·>Как я понял ты это всё в одиночку разрабатывал, иначе не мужик.


Не всегда, но в том числе. Так что я знаю, на что способен — в отличие от тебя с твоим "модулем для сохранения данных в таблице"

·>с затратами порядка хотя бы 100-1000 человеко-лет.


100-1000 макако-лет — это вообще ничего не говорит.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[33]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 02:49
Оценка:
Здравствуйте, ·, Вы писали:

·>Ужас. И как? Больно было?


Тебе должно быть виднее, как это бывает

·>Сохранение FX market data в таблице? СУБД имеешь в виду?


Ну откуда я знаю, где там у тебя что хранилось? Раз скрываешь — значит, самому стыдно.

·>А что говорит?


Описание функционала.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[24]: Плюсы лучших методологий юнит тестирования.
От: Sharov Россия  
Дата: 29.12.17 09:57
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>Ты действительно думаешь, что не написав самостоятельно ни одной мало-мальски сложной программы, можешь вообще называться программистом?


Озвучьте критерий
А то есть rocket science, плодами которого пользуются от силы десяток людей, а есть не очень сложный код, которым пользуются миллионы. И те и другие, на мой взгляд,хорошие программисты.
Только одни сильнее в физике\математике, а другие в маркетинге.
Кодом людям нужно помогать!
Re[25]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 16:39
Оценка:
Здравствуйте, Sharov, Вы писали:

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

S>Только одни сильнее в физике\математике, а другие в маркетинге.

Как ты сам озвучил — хорошие маркетологи, а не программисты.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[25]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 16:39
Оценка:
Здравствуйте, itslave, Вы писали:

I>Ну во первых я уверен, что 'Hello world' писали все. Подпадает под критерий "мало-мальски сложной программы"




I>, только многие не считают это фактом, заслуживающим упоминания. Во вторых я так же уверен в том, что сколько-нибудь сложные проекты делаются коллективами


А мне почему-то кажется, что между hello world и монстром типа линукса есть немало промежуточных этапов.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[27]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 16:54
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Критерий будет?


Сложность решенной задачи.

S>Мне лично кажется, что это круто, когда миллионы людей пользуются твоим кодом, пусть даже не супер-пупер сложным.


Круто, но это маркетинг, а не программирование.

S>Могу для затравки критерия предложить такое понятие как польза обществу.


Сразу вспоминается "Серийный программист Джон".
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[35]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 17:16
Оценка:
Здравствуйте, ·, Вы писали:

·>Ты только что написал, что с тобой так же было. Путаешься в показаниях?


Со мной было так, что я работал в некоторых проектах один и в некоторых в команде. А что было у тебя, от чего должно быть больно — это только тебе известно.

·>Т.е. нифига не знаешь, но выводы сделать готов.


Попытки замутить воду с твоей стороны — тоже неплохое основание для выводов.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[37]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 17:29
Оценка:
Здравствуйте, ·, Вы писали:

·>Но ты вроде сказал, что работать надо в одиночку, иначе нуб.


Если ты можешь работать в одиночку, то ты не нуб. Делать это всегда необязательно.
Ну а если не можешь, то, естественно, нуб.

·>Я пользуюсь публично известными терминами. Если ты не их знаешь — погугли, копипастить я это не буду. Если ты не умеешь пользоваться гуглом, то могу дать уроки Пользователя ПК. Дорого.


Нет, ты просто мутишь воду. Никаких деталей я так и не увидел.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[30]: Плюсы лучших методологий юнит тестирования.
От: Sharov Россия  
Дата: 29.12.17 17:45
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>Сложно раскрутить, поскольку процесс это нелогичный и сильно зависит от случайности. Разработать — намного проще.


Разработать, чтобы масштабировалось для миллионов пользователей просто? Angry birds тоже не легко сделать, если что.
Кодом людям нужно помогать!
Re[39]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 18:23
Оценка:
Здравствуйте, ·, Вы писали:

·>Программа, которую может написать человек в одиночку — сложно назвать сложной, хотя в мире могут быть единичные случаи.


"Программа, которую может написать нуб в одиночку". Небольшая поправка.

·>А какие детали ты спрашивал?


Ну начнем с того, что это тебе следовало начать с деталей, а не с надувания щек.
И во вторых — так что и где там сохраняется в твоем модуле?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[31]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 18:23
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Разработать, чтобы масштабировалось для миллионов пользователей просто? Angry birds тоже не легко сделать, если что.


А что там "масштабируется для миллионов пользователей" в Angry birds?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[32]: Плюсы лучших методологий юнит тестирования.
От: Sharov Россия  
Дата: 29.12.17 18:31
Оценка:
Здравствуйте, CoderMonkey, Вы писали:


CM>А что там "масштабируется для миллионов пользователей" в Angry birds?


Не правильно поняли -- или-или. Т.е. какой-нибудь сервис для миллионов запилить не просто. Так и standalone мобильное приложение, чтобы миллионы зацепить, разработать не просто. Хотя в обоих случаях особых сложностей может и не быть. Знать хорошо свой инструмент и технологии, и знать потребности рынка.
Кодом людям нужно помогать!
Re[39]: Плюсы лучших методологий юнит тестирования.
От: Sharov Россия  
Дата: 29.12.17 19:40
Оценка:
Здравствуйте, ·, Вы писали:

·>И что в этом сложного? Так и работал студентом, да в начале карьеры. Программа, которую может написать человек в одиночку — сложно назвать сложной, хотя в мире могут быть единичные случаи.

·>Работать в команде — сложнее.

Справедливости ради, всяческие движки для чего-нибудь, требующие активно использовать соотв. мат. аппарат. мало кто может сделать. Здесь есть одиночки, и это действительно бывает трудно. Особенно понять код.
Кодом людям нужно помогать!
Re[33]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 20:40
Оценка:
Здравствуйте, Sharov, Вы писали:

S>и знать потребности рынка.


Вот именно здесь собака и порылась. Где сейчас Смоллток, например? Или где Амига?
Технологии они знали отлично, а вот продать не смогли.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Отредактировано 29.12.2017 20:41 CodeMonkey . Предыдущая версия .
Re[41]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 29.12.17 20:40
Оценка:
Здравствуйте, ·, Вы писали:

·>Без разницы. Максимум может быть ценна идея — а давай-ка я забабахаю ещё одно ядро юникса с такими-то фичами — но таки до сложной вещи типа Линукса это доводится командой.


Как я уже писал — между hello world и проектами-монстрами типа оси есть еще очень много промежуточных этапов.

·>market data — это по сути поток ордеров. Нужно их писать с минимальной задержкой (порядка 1мс). И давать читать, не мешая писателю писать. Данных примерно 5Tb. СУБД не справляются, пришлось писать свою имплементацию с перф-тестами и бледжеком.


И даже не упомянул, есть ли там какие-то индексы или это просто "в каком порядке принял, так и записал". Это к вопросу о твоем уровне опыта.
В любом случае, 5 тб при современном железе — это мелочь.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[34]: Плюсы лучших методологий юнит тестирования.
От: Sharov Россия  
Дата: 29.12.17 21:38
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>Вот именно здесь собака и порылась. Где сейчас Смоллток, например? Или где Амига?

CM>Технологии они знали отлично, а вот продать не смогли.

Ну и? Если у кого-то не получилось, не значит, что у всех не получится. Найдутся люди, которые и сделают и продадут.
Кодом людям нужно помогать!
Re[35]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 30.12.17 02:44
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Ну и? Если у кого-то не получилось, не значит, что у всех не получится. Найдутся люди, которые и сделают и продадут.


Это значит, что умение раскрутить проект — это именно вопрос маркетологии, а не программирования. А раскрутить можно и полное говно, как бывало уже не раз.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[27]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 30.12.17 02:44
Оценка:
Здравствуйте, itslave, Вы писали:

I>И большинство из этих "этапов" — работа в коллективе. Тот же линукс сегодня — это банальная командная разработка.


Как правило, просто потому, что менеджер с маленькой командой — это просто полный лох в глазах других менеджеров
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[45]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 30.12.17 04:56
Оценка:
Здравствуйте, itslave, Вы писали:

I>Это вброс, или ты ничего больше hello world не писал никогда?


Я — писал, и пишу.
А ты действительно думаешь, что ты самый лучший программист в мире и лучше тебя не может быть никто?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[29]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 30.12.17 05:00
Оценка:
Здравствуйте, itslave, Вы писали:

I>Да возьми любой успешный опенсорс продукт — везде команды.


Опенсорс пилят обычно в качестве хобби (то есть времени на него очень мало), либо это самый обычный проект с манагерами, только опен сорс.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[46]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 30.12.17 05:53
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>Я — писал, и пишу.

... проекты обьемами с hello world.

CM>А ты действительно думаешь, что ты самый лучший программист в мире и лучше тебя не может быть никто?

Я в общем то даже не совсем программист уже, ну да ет такое. Главное — ты без членомеряния никак.
Re[22]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 30.12.17 06:49
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

·>>Но если так интересно, одна из запомнившихся задач — переписал модуль хранения market data, для улучшения перформанса.


CM>То есть, ни одной серьезной задачи ты никогда в жизни не решал.


Это таки очень серьёзная задача.
Несколько десятков дебильных (легаси) форматов транспорта, необходимость быстрой конверсии, удобного универсального хранения, быстрого поиска по нескольким типовым критериям (хранение как в реляционках обычно не подходит), и всё это со входными потоками гигабиты в секунду на одну установку.
The God is real, unless declared integer.
Re[4]: Плюсы лучших методологий юнит тестирования.
От: Cyberax Марс  
Дата: 30.12.17 06:50
Оценка:
Здравствуйте, netch80, Вы писали:

N>Для унылого клеевого кода типа "взять шарик фарша, макнуть в сухари и плюхнуть на сковородку", коего большинство даже во вполне интересных проектах, юнит-тесты будут только наворачивать строки кода без реальной пользы.

Категорически несогласен.

Юнит-тесты ЗАСТАВЛЯЮТ писать код так, чтобы его было легко тестировать. А это существенно улучшает архитектуру, так как DI и SRP вытекают практически автоматически.

А интеграционные тесты редко получается делать всеобъемлющими, особенно при тестировании реакций на такие вещи как внутренние сбои и нарушения целостности данных.
Sapienti sat!
Re[7]: Плюсы лучших методологий юнит тестирования.
От: Cyberax Марс  
Дата: 30.12.17 06:53
Оценка:
Здравствуйте, Sharov, Вы писали:

S>·>???!!! В юнит-тестах вроде обычно мокируют всё кроме собственно тестируемого юнита.

S>В данном случае придется мокировать тестируемый юнит Берд конечно, но я не представляю себе юнит-тестов для работы с фс. Это уже не ют.
А какие проблемы? Обычно работа с ФС заключается в использовании потоков. Их прекрасно можно заменять на ByteArray(Input|Output)Stream или их аналоги.

Хотя если работа нужна с конкретно файлами, то обычно при этом уже есть завязка на семантику конкретной ОС и юнит-тесты уже менее применимы. Зато сразу же возникает естественное давление, заставляющее вынести всю системно-зависимую часть в тонкую обособленную прослойку.
Sapienti sat!
Re[5]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 30.12.17 07:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

N>>Для унылого клеевого кода типа "взять шарик фарша, макнуть в сухари и плюхнуть на сковородку", коего большинство даже во вполне интересных проектах, юнит-тесты будут только наворачивать строки кода без реальной пользы.

C>Категорически несогласен.
C>Юнит-тесты ЗАСТАВЛЯЮТ писать код так, чтобы его было легко тестировать. А это существенно улучшает архитектуру, так как DI и SRP вытекают практически автоматически.

Да, есть такая точка зрения (и я её во многом поддерживаю) — например, Michael Feathers очень хорошо описал свою концепцию. Так что именно мне можешь не рассказывать

Только вот проблема в том, что DI и SRP не могут быть самоцелью: SRP это маргинализация естественного способа справиться со сложностью выделением умозрительных границ между сущностями — и это видно по тому, что часто нет единого мнения о том, как именно проводить эти границы. А DI для него не более чем главный из вспомогательных подходов реализации.

Твой соседний пример с абстрагированием файлов как потоков очень показателен в этом плане. Когда мы читаем/пишем их последовательно — ok. А если это БД? А вот Clang свои входные файлы mmapʼит. Ты можешь это, конечно, замокать построением char[] на входе, и абстракция буфера давно есть, но фундаментально в таком тесте разницы с реальным файлом уже нет.

C>А интеграционные тесты редко получается делать всеобъемлющими, особенно при тестировании реакций на такие вещи как внутренние сбои и нарушения целостности данных.


Если "всеобъемлющими" это 100% покрытие кода и сценариев, то ты на уровне юнит-тестов часто не сможешь сформулировать противоречия в ТЗ — а это всегда ещё одна цель построения тестов. А если они разобраны, и поведение детерминировано, то принципиальных проблем с покрытием нет. Они могут быть в духе "слишком сложно считать все комбинации", тут согласен. А ещё есть случаи недетерминированного поведения (и их всё больше благодаря нейросетям и т.п.) Вот там, да, без тестов более низкого уровня (не надо говорить "юнит", это неадекватный термин) не обойтись.
The God is real, unless declared integer.
Re[14]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 30.12.17 07:20
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

·>>Тут ведь как. Приходит заказчик и говорит — вот тут у тебя прога выдаёт 24, а должно быть 42.


CM>Тэорэтики такие тэорэтики.


Я тоже попадал в такие ситуации. Решаются именно описанным подходом.
А вот что коллега ·@ не описал — проблемы собственно с заказчиком (может, у него такого не было) — от "обойдитесь минимальной переделкой" до "я не могу это принимать на свой продакшен сейчас, ждите полгода, а сейчас рисуйте простой обход, который я бы сам понял в деталях".
The God is real, unless declared integer.
Re[6]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 30.12.17 07:37
Оценка:
Здравствуйте, Ведмедь, Вы писали:

В>>>>Просто потому что с юнит тестами большинство багов не дошло прошло бы первый коммит.

CM>>>Фуфло. Никакие юнит тесты ничего не гарантируют, поскольку от ошибок понимания ТЗ не спасают, и даже для более примитивных багов тоже ничего не гарантируют, поскольку сами могут содержать ошибки.

N>>Ну против таких ситуаций есть метод требовать написание тестов не автором кода, а именно QC сотрудниками.

N>>Jef239@habr настойчиво рекомендовал такой вариант ещё и потому, что тестеры значительно дешевле.

В>Эм. как мне кажется тут есть путаница между функциональными автотестами и юниттестами. Функциональные автотесты должны писать как раз QA, а юнит тесты авторы кода.


Не то чтобы путаница, но Jef239 их, похоже, принципиально тут не разделял. На уровне одной функции оба комплекта сводятся к проверке результата при конкретных аргументах. Разница идёт в другом (далее описываю в основном уже с опорой на свой опыт): все подобные тесты достаточно чётко разделяются на проверку типичных случаев и сценариев, и проверку маргинальных вариантов. Например, если мы пишем умножение 16-битных чисел, то типичным будет 0*0 и 2*2, а маргинальным — (-32768)*2. И оценка обоих комплектов типичных и маргинальных вариантов может быть заметно различной между собственно автором кода и внешним тестером: внешний пишет по ТЗ (наверно, это и есть твоё "функциональные автотесты"), а автор обязан учесть реализацию, потому что за него это никто не сделает.
А вот если внешний тестер начнёт гадать о внутренней реализации — вот это меня всегда смущало в описанном подходе (тут уже снова не на своём опыте, потому что я как раз отрабатывал маргинальные случаи сам, сколько их видел).

В>Функциональные тесты по ТЗ делаются на систему как на черный ящик, юнит тесты на часть системы как на белый ящик (да еще с моками без учета окружения)


Вот я и говорю — такое разделение подозрительно жёсткое. В реальности между ними возникает естественное заметное перекрытие. Я вообще не приемлю отделение юнит-тестов от функциональных: юнит-тесты это всего лишь самый нижний уровень функциональных (а интеграционные — верхний), и это можно понять тогда, когда обнаруживаешь, что тестировать подблок как "чёрный ящик" и важнее, и эффективнее, чем пытаться мокать его не только снаружи, но и изнутри.
The God is real, unless declared integer.
Re[23]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 30.12.17 11:16
Оценка:
Здравствуйте, netch80, Вы писали:

CM>>То есть, ни одной серьезной задачи ты никогда в жизни не решал.

N>Это таки очень серьёзная задача.
N>Несколько десятков дебильных (легаси) форматов транспорта, необходимость быстрой конверсии, удобного универсального хранения, быстрого поиска по нескольким типовым критериям (хранение как в реляционках обычно не подходит), и всё это со входными потоками гигабиты в секунду на одну установку.
Да не... у меня попроще было. Там своя маркет-дата пишется, никакого легаси. Хотя переезд со старого хранилища на новое — тоже свои приколы, при размерах в терабайты вспоминаешь, что диски имеют ограниченный размер.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: Плюсы лучших методологий юнит тестирования.
От: Cyberax Марс  
Дата: 01.01.18 05:49
Оценка:
Здравствуйте, netch80, Вы писали:

N>Только вот проблема в том, что DI и SRP не могут быть самоцелью: SRP это маргинализация естественного способа справиться со сложностью выделением умозрительных границ между сущностями — и это видно по тому, что часто нет единого мнения о том, как именно проводить эти границы. А DI для него не более чем главный из вспомогательных подходов реализации.

SRP и DI — это вообще единственное хорошее изобретение в ООП с начала 90-х (если не 80-х). А что конкретно в SRP не так?

N>Твой соседний пример с абстрагированием файлов как потоков очень показателен в этом плане. Когда мы читаем/пишем их последовательно — ok. А если это БД? А вот Clang свои входные файлы mmapʼит. Ты можешь это, конечно, замокать построением char[] на входе, и абстракция буфера давно есть, но фундаментально в таком тесте разницы с реальным файлом уже нет.

Я не очень понял в чём пример. Код работает с прослойкой FS, которая в Clang составляет менее 0.5% общего кода. Прослойка элементарно mock'ается в зависимом коде, как конкретно это делать — вопрос отдельный.

C>>А интеграционные тесты редко получается делать всеобъемлющими, особенно при тестировании реакций на такие вещи как внутренние сбои и нарушения целостности данных.

N>Если "всеобъемлющими" это 100% покрытие кода и сценариев, то ты на уровне юнит-тестов часто не сможешь сформулировать противоречия в ТЗ — а это всегда ещё одна цель построения тестов.
Задача юнит-тестов — это не находить противоречия в ТЗ (Что это вообще такое? Ни разу не видел), а следить за тем, чтобы код не регрессировал при рефакторинге и багфиксинге. Ну и плюс дополнительная документация на сам код.

Тестирование на соответствие ТЗ — это уже специфично для каждой области и может быть очень разным.
Sapienti sat!
Re[7]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.01.18 12:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

N>>Только вот проблема в том, что DI и SRP не могут быть самоцелью: SRP это маргинализация естественного способа справиться со сложностью выделением умозрительных границ между сущностями — и это видно по тому, что часто нет единого мнения о том, как именно проводить эти границы. А DI для него не более чем главный из вспомогательных подходов реализации.

C>SRP и DI — это вообще единственное хорошее изобретение в ООП с начала 90-х (если не 80-х). А что конкретно в SRP не так?

DI было задолго до 80-х. SRP — согласен. А что не так — я уже сказал выше.

N>>Твой соседний пример с абстрагированием файлов как потоков очень показателен в этом плане. Когда мы читаем/пишем их последовательно — ok. А если это БД? А вот Clang свои входные файлы mmapʼит. Ты можешь это, конечно, замокать построением char[] на входе, и абстракция буфера давно есть, но фундаментально в таком тесте разницы с реальным файлом уже нет.

C>Я не очень понял в чём пример. Код работает с прослойкой FS, которая в Clang составляет менее 0.5% общего кода. Прослойка элементарно mock'ается в зависимом коде, как конкретно это делать — вопрос отдельный.

В том, что ты хочеш потоки. Когда требуется что-то, что потоки не умеют (например, массовый ungetc).
Впрочем, я уверен, что ты и так понимаешь их ограничения, поэтому это не является существенной проблемой — поменять абстракцию по необходимости. Типа, проехали.

C>>>А интеграционные тесты редко получается делать всеобъемлющими, особенно при тестировании реакций на такие вещи как внутренние сбои и нарушения целостности данных.

N>>Если "всеобъемлющими" это 100% покрытие кода и сценариев, то ты на уровне юнит-тестов часто не сможешь сформулировать противоречия в ТЗ — а это всегда ещё одна цель построения тестов.
C>Задача юнит-тестов — это не находить противоречия в ТЗ (Что это вообще такое? Ни разу не видел),

Тебе просто фантастически повезло.

C> а следить за тем, чтобы код не регрессировал при рефакторинге и багфиксинге. Ну и плюс дополнительная документация на сам код.


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

C>Тестирование на соответствие ТЗ — это уже специфично для каждой области и может быть очень разным.


Но подавляющее большинство таких проверок всё равно укладываются в стандартную концепцию тестов и в соответствующие фреймворки.
The God is real, unless declared integer.
Re[8]: Плюсы лучших методологий юнит тестирования.
От: Cyberax Марс  
Дата: 02.01.18 07:12
Оценка:
Здравствуйте, netch80, Вы писали:

C>>SRP и DI — это вообще единственное хорошее изобретение в ООП с начала 90-х (если не 80-х). А что конкретно в SRP не так?

N>DI было задолго до 80-х. SRP — согласен. А что не так — я уже сказал выше.
Границы SRP? Они в любом случае будут размытыми, но есть практические правила, которые почти всегда работают. Типа не более 3-4 зависимостей в классе и т.п.

C>>Я не очень понял в чём пример. Код работает с прослойкой FS, которая в Clang составляет менее 0.5% общего кода. Прослойка элементарно mock'ается в зависимом коде, как конкретно это делать — вопрос отдельный.

N>В том, что ты хочеш потоки. Когда требуется что-то, что потоки не умеют (например, массовый ungetc).
Я не хочу потоки, просто упомянул их в качестве примера.

C>>Задача юнит-тестов — это не находить противоречия в ТЗ (Что это вообще такое? Ни разу не видел),

N>Тебе просто фантастически повезло.
Я про ТЗ, никогда не было именно ТЗ в классическом понимании. Максимум были технические требования. Обычно было описание того, как фичи должны выглядеть стороны заказчика.

C>> а следить за тем, чтобы код не регрессировал при рефакторинге и багфиксинге. Ну и плюс дополнительная документация на сам код.

N>В задачу любых тестов входит контроль отсутствия регрессий, и неважно, почему они случились. Тут юнит-тесты ничем не выделяются — как уже говорил, это всего лишь частный случай функциональных тестов.
Юнит-тесты работают намного раньше интеграционных — во время разработки. В частности, их можно запускать, даже пока код всего проекта сломан, и вообще не компилируется целиком. Для интеграционных тестов уже нужна полноценно работающая система.

C>>Тестирование на соответствие ТЗ — это уже специфично для каждой области и может быть очень разным.

N>Но подавляющее большинство таких проверок всё равно укладываются в стандартную концепцию тестов и в соответствующие фреймворки.
Необязательно. Например, у нас продукт — это сетевой API. Для тестов стандартные framework'и уже не очень подходят, особенно учитывая, что некоторые workflow могут занимать по нескольку часов и влиять на другие тесты. Стандартные тестовые framework'и так же плохо подходят для нагрузочного тестирования.

У соседей, которые занимаются более низким уровнем, тесты включают аппаратный стенд для проверки работы при потере питания.

У других соседей, тесты включают автоматизацию браузеров и AI для проверки того, что данные на экране выглядят нормально (разметка не поехала, элементы отзывчивы и т.п.).

В общем, по моему опыту для интеграционных тестов сложно что-то реально универсальное найти.
Sapienti sat!
Re[9]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 02.01.18 08:36
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>SRP и DI — это вообще единственное хорошее изобретение в ООП с начала 90-х (если не 80-х). А что конкретно в SRP не так?

N>>DI было задолго до 80-х. SRP — согласен. А что не так — я уже сказал выше.
C>Границы SRP? Они в любом случае будут размытыми, но есть практические правила, которые почти всегда работают. Типа не более 3-4 зависимостей в классе и т.п.

Ну вот именно что размытые... и я реально видел, как на этих размытых границах возникали жуткие флеймы.
И "почти" всегда тут характерно — у меня бывали случаи, когда разделить таким образом невозможно — всё рассыпается.

C>>>Задача юнит-тестов — это не находить противоречия в ТЗ (Что это вообще такое? Ни разу не видел),

N>>Тебе просто фантастически повезло.
C>Я про ТЗ, никогда не было именно ТЗ в классическом понимании. Максимум были технические требования. Обычно было описание того, как фичи должны выглядеть стороны заказчика.

Ааа... ну мы всё-таки обычно так не работали. Про описанию от заказчика строились техусловия (ТУ) (название не идеальное, но надо ж было как-то назвать), далее — ТЗ, которые уже утверждались (если у заказчика — вообще отлично, но и без него справлялись) — и по ним работали.

C>>> а следить за тем, чтобы код не регрессировал при рефакторинге и багфиксинге. Ну и плюс дополнительная документация на сам код.

N>>В задачу любых тестов входит контроль отсутствия регрессий, и неважно, почему они случились. Тут юнит-тесты ничем не выделяются — как уже говорил, это всего лишь частный случай функциональных тестов.
C>Юнит-тесты работают намного раньше интеграционных — во время разработки. В частности, их можно запускать, даже пока код всего проекта сломан, и вообще не компилируется целиком. Для интеграционных тестов уже нужна полноценно работающая система.

Ну вот ты тоже думаешь этими тупыми шаблонами про "юнит" и "интеграционные". Нет такого разделения в их сути. Есть функциональные тесты разных уровней, и на каждом уровне их можно строить по-своему.
Не обязательно тестировать только функции самого нижнего уровня, или обкладывать моками все проявления более высоких уровней. Можно делать функциональные тесты на первом уровне (которые юнит), на втором (включая весь первый; даже если он сам по себе ещё не обложен тестами), и так далее.
И да, какая-то часть может быть ещё не написана ("не компилируется" — такое понятие не применяли — считаем тем же, что не написано, практически этого было достаточно) — остальные части можно и нужно тестировать.
Чем выше уровень конструкции тестируемого кода, тем больше обстановка запуска приближается к реальной, и тем ближе оно к этому филистерскому понятию "интеграционных тестов" — но всё равно эту обстановку можно строить и применять.

C>>>Тестирование на соответствие ТЗ — это уже специфично для каждой области и может быть очень разным.

N>>Но подавляющее большинство таких проверок всё равно укладываются в стандартную концепцию тестов и в соответствующие фреймворки.
C>Необязательно. Например, у нас продукт — это сетевой API.

Наверно ж, не только API, а и его реализация?

C> Для тестов стандартные framework'и уже не очень подходят, особенно учитывая, что некоторые workflow могут занимать по нескольку часов и влиять на другие тесты. Стандартные тестовые framework'и так же плохо подходят для нагрузочного тестирования.

C>У соседей, которые занимаются более низким уровнем, тесты включают аппаратный стенд для проверки работы при потере питания.
C>У других соседей, тесты включают автоматизацию браузеров и AI для проверки того, что данные на экране выглядят нормально (разметка не поехала, элементы отзывчивы и т.п.).
C>В общем, по моему опыту для интеграционных тестов сложно что-то реально универсальное найти.

Я бы это не называл уже интеграционными. Тут нужно другое слово, адекватно описывающее влияние внешнего воздействия.
The God is real, unless declared integer.
Re[10]: Плюсы лучших методологий юнит тестирования.
От: Cyberax Марс  
Дата: 02.01.18 10:58
Оценка:
Здравствуйте, netch80, Вы писали:

C>>Границы SRP? Они в любом случае будут размытыми, но есть практические правила, которые почти всегда работают. Типа не более 3-4 зависимостей в классе и т.п.

N>Ну вот именно что размытые... и я реально видел, как на этих размытых границах возникали жуткие флеймы.
Флеймы будут возникать по любому поводу. С SRP хотя бы хорошо то, что он будет помогать избегать самых явных нарушений.

C>>Я про ТЗ, никогда не было именно ТЗ в классическом понимании. Максимум были технические требования. Обычно было описание того, как фичи должны выглядеть стороны заказчика.

N>Ааа... ну мы всё-таки обычно так не работали. Про описанию от заказчика строились техусловия (ТУ) (название не идеальное, но надо ж было как-то назвать), далее — ТЗ, которые уже утверждались (если у заказчика — вообще отлично, но и без него справлялись) — и по ним работали.
У меня практически всегда сначала рисуется список требований, дальше делается грубый технический план с архитектурой и вперёд с песней.

C>>Юнит-тесты работают намного раньше интеграционных — во время разработки. В частности, их можно запускать, даже пока код всего проекта сломан, и вообще не компилируется целиком. Для интеграционных тестов уже нужна полноценно работающая система.

N>Ну вот ты тоже думаешь этими тупыми шаблонами про "юнит" и "интеграционные". Нет такого разделения в их сути. Есть функциональные тесты разных уровней, и на каждом уровне их можно строить по-своему.
Разделение есть. Интеграционные тесты работают на уровне всей системы — по определению. И тестируют работу системы в связке со всем окружением.

N>Не обязательно тестировать только функции самого нижнего уровня, или обкладывать моками все проявления более высоких уровней. Можно делать функциональные тесты на первом уровне (которые юнит), на втором (включая весь первый; даже если он сам по себе ещё не обложен тестами), и так далее.

Юнит тесты никак не могут являться функциональными тестами, так как не работают в реальном окружении.

C>>Необязательно. Например, у нас продукт — это сетевой API.

N>Наверно ж, не только API, а и его реализация?
Ага.

C>>У других соседей, тесты включают автоматизацию браузеров и AI для проверки того, что данные на экране выглядят нормально (разметка не поехала, элементы отзывчивы и т.п.).

C>>В общем, по моему опыту для интеграционных тестов сложно что-то реально универсальное найти.
N>Я бы это не называл уже интеграционными. Тут нужно другое слово, адекватно описывающее влияние внешнего воздействия.
Это и называется "интеграционные тесты". Т.е. тесты всей системы в сборе, в реальных условиях.
Sapienti sat!
Re[11]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 02.01.18 12:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Границы SRP? Они в любом случае будут размытыми, но есть практические правила, которые почти всегда работают. Типа не более 3-4 зависимостей в классе и т.п.

N>>Ну вот именно что размытые... и я реально видел, как на этих размытых границах возникали жуткие флеймы.
C>Флеймы будут возникать по любому поводу. С SRP хотя бы хорошо то, что он будет помогать избегать самых явных нарушений.

В таком варианте — ok. Главное — не абсолютизировать его.

C>>>Я про ТЗ, никогда не было именно ТЗ в классическом понимании. Максимум были технические требования. Обычно было описание того, как фичи должны выглядеть стороны заказчика.

N>>Ааа... ну мы всё-таки обычно так не работали. Про описанию от заказчика строились техусловия (ТУ) (название не идеальное, но надо ж было как-то назвать), далее — ТЗ, которые уже утверждались (если у заказчика — вообще отлично, но и без него справлялись) — и по ним работали.
C>У меня практически всегда сначала рисуется список требований, дальше делается грубый технический план с архитектурой и вперёд с песней.

Ясно.

C>>>Юнит-тесты работают намного раньше интеграционных — во время разработки. В частности, их можно запускать, даже пока код всего проекта сломан, и вообще не компилируется целиком. Для интеграционных тестов уже нужна полноценно работающая система.

N>>Ну вот ты тоже думаешь этими тупыми шаблонами про "юнит" и "интеграционные". Нет такого разделения в их сути. Есть функциональные тесты разных уровней, и на каждом уровне их можно строить по-своему.
C>Разделение есть. Интеграционные тесты работают на уровне всей системы — по определению.

А если часть системы тоже имеет полезную функциональность?

N>>Не обязательно тестировать только функции самого нижнего уровня, или обкладывать моками все проявления более высоких уровней. Можно делать функциональные тесты на первом уровне (которые юнит), на втором (включая весь первый; даже если он сам по себе ещё не обложен тестами), и так далее.

C>Юнит тесты никак не могут являться функциональными тестами, так как не работают в реальном окружении.

С чего это функциональные тесты работают "в реальном окружении", и насколько оно иначе нереально?

C>>>В общем, по моему опыту для интеграционных тестов сложно что-то реально универсальное найти.

N>>Я бы это не называл уже интеграционными. Тут нужно другое слово, адекватно описывающее влияние внешнего воздействия.
C>Это и называется "интеграционные тесты". Т.е. тесты всей системы в сборе, в реальных условиях.

Интеграционные точно также могут быть и для подсистем.
The God is real, unless declared integer.
Re[12]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 02.01.18 13:01
Оценка:
Здравствуйте, ·, Вы писали:

C>>Разделение есть. Интеграционные тесты работают на уровне всей системы — по определению. И тестируют работу системы в связке со всем окружением.

C>>Юнит тесты никак не могут являться функциональными тестами, так как не работают в реальном окружении.
·>Тут уже по-моему вопрос терминологии. У нас были такие термины:
·>Юнит-тесты — их много, они сверхбыстрые, запускаешь их всех ещё перед коммитом. Тестируют небольшой кусок кода (обычно один класс, бывает чуть больше).
·>Интеграционные тесты — их меньше, тестируют взаимодействие кода с другими компонентами. Например, DAO <-> dbms, FIX-gateway <-> FIX-клиент, сокеты, файлы, етс. Их меньше, работают долго, т.к. требуют, например, запустить какой-нибудь mysql, залить тестовыми данными и т.п.

Вот. Для интеграционных проверяется само взаимодействие, а не внешний функционал сводной системы.

·>Приёмочные тесты (acceptance tests) — запуск системы практически целиком и тестирование полных сценариев, соответсвующих бизнес-требованиям. Работают пол часа на кластере из сотни компов, на машине разработчика их все запустить нереально.

·>Т.е. интеграционные тесты в идеале тестируют интеграцию двух компонент, а приёмочные — тестируют всю систему целиком.

·>Это одна ось. Другая ось — функциональные тесты/нефункциональные. Это соответсвует функциональным требованиям/нефункциональным. Т.е. "Система должна продать слона" — это функциональное требование, А "система должна способна продавать до 1000 слонов в секунду даже при падении одного из серверов" — это уже нефункциональное. Значит, всякие перформанс-тесты, тесты recovery, бэкапов, staging, миграции — это всё нефункциональные. Они, как правило, интеграционные. Но ничто не мешает сделать небольшой юнит-тест для измерения перформанса некоего юнита.


Производительность, секьюрити и т.д. — это, наверно, тоже функциональные, если их требования заложены в ТЗ.
Нефункциональные тесты — это, например, проверка стиля кода.
The God is real, unless declared integer.
Re[13]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 02.01.18 14:00
Оценка:
Здравствуйте, netch80, Вы писали:

N>Вот. Для интеграционных проверяется само взаимодействие, а не внешний функционал сводной системы.

Ну да. В небольших системах это может быть вырожденный случай и они совпадают. А в совсем маленьких системах все три типа — юнит/инт/приёмочные могут совпадать.

N>·>Это одна ось. Другая ось — функциональные тесты/нефункциональные. Это соответсвует функциональным требованиям/нефункциональным. Т.е. "Система должна продать слона" — это функциональное требование, А "система должна способна продавать до 1000 слонов в секунду даже при падении одного из серверов" — это уже нефункциональное. Значит, всякие перформанс-тесты, тесты recovery, бэкапов, staging, миграции — это всё нефункциональные. Они, как правило, интеграционные. Но ничто не мешает сделать небольшой юнит-тест для измерения перформанса некоего юнита.

N>Производительность, секьюрити и т.д. — это, наверно, тоже функциональные, если их требования заложены в ТЗ.
Нет, вроде есть устоявщийся официальный термин: https://en.wikipedia.org/wiki/Non-functional_requirement
Т.е. отличают не где что заложено (ТЗ уж слишком широкий термин), а отличие того "что система делает" (поведение) от "как система делает" (операционные качества).

N>Нефункциональные тесты — это, например, проверка стиля кода.

Это ещё одна ось. Функциональные/нефункциональные требования — это всё взаимодействие бизнеса с разработчиками. А проверка стиля кода и т.п. это дело чисто разработчиков, бизнес вообще в таком участия не принимает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: Плюсы лучших методологий юнит тестирования.
От: Cyberax Марс  
Дата: 02.01.18 20:03
Оценка:
Здравствуйте, netch80, Вы писали:

C>>Разделение есть. Интеграционные тесты работают на уровне всей системы — по определению.

N>А если часть системы тоже имеет полезную функциональность?
Это тоже будут интеграционные тесты, они могут быть вложенными.

C>>Юнит тесты никак не могут являться функциональными тестами, так как не работают в реальном окружении.

N>С чего это функциональные тесты работают "в реальном окружении", и насколько оно иначе нереально?
Ну если код чисто вычислительный — тогда возможно, так как в данном случае они будут тождественны.

Но юнит-тесты по всем рекомендациям не должны зависеть от внешних сервисов, они рассматриваются как часть процесса компиляции. Например, у нас они вообще выполняются в контейнерах с начисто отключенной сетью.

N>>>Я бы это не называл уже интеграционными. Тут нужно другое слово, адекватно описывающее влияние внешнего воздействия.

C>>Это и называется "интеграционные тесты". Т.е. тесты всей системы в сборе, в реальных условиях.
N>Интеграционные точно также могут быть и для подсистем.
Конечно. Системы могут быть многоуровневыми, с интеграционными тестами на нескольких уровнях. Это вполне нормально.
Sapienti sat!
Re[14]: Плюсы лучших методологий юнит тестирования.
От: itslave СССР  
Дата: 02.01.18 20:45
Оценка:
Здравствуйте, ·, Вы писали:

·>Это ещё одна ось. Функциональные/нефункциональные требования — это всё взаимодействие бизнеса с разработчиками. А проверка стиля кода и т.п. это дело чисто разработчиков, бизнес вообще в таком участия не принимает.

Нет. Строго говоря, качество кода включая и стили кодирования — это такое самое nfr как и перформанс. Вполне себе нормально выражается в таких qa как maintainability, conceptual integrity, reusability testability.
Их вполне можно и нужно обсуждать с бизнесом. На языке, понятном бизнесу ессна ж
Re[13]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.01.18 06:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Разделение есть. Интеграционные тесты работают на уровне всей системы — по определению.

N>>А если часть системы тоже имеет полезную функциональность?
C>Это тоже будут интеграционные тесты, они могут быть вложенными.

Это такие же функциональные тесты.

C>>>Юнит тесты никак не могут являться функциональными тестами, так как не работают в реальном окружении.

N>>С чего это функциональные тесты работают "в реальном окружении", и насколько оно иначе нереально?
C>Ну если код чисто вычислительный — тогда возможно, так как в данном случае они будут тождественны.

И не для чисто вычислительного тоже.

C>Но юнит-тесты по всем рекомендациям не должны зависеть от внешних сервисов, они рассматриваются как часть процесса компиляции. Например, у нас они вообще выполняются в контейнерах с начисто отключенной сетью.


А я внешние сервисы и не предлагал.

N>>>>Я бы это не называл уже интеграционными. Тут нужно другое слово, адекватно описывающее влияние внешнего воздействия.

C>>>Это и называется "интеграционные тесты". Т.е. тесты всей системы в сборе, в реальных условиях.
N>>Интеграционные точно также могут быть и для подсистем.
C>Конечно. Системы могут быть многоуровневыми, с интеграционными тестами на нескольких уровнях. Это вполне нормально.

Ну вот потому и не надо говорить/думать про самый верхний уровень.
The God is real, unless declared integer.
Re[47]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 03.01.18 23:21
Оценка:
Здравствуйте, itslave, Вы писали:

I>... проекты обьемами с hello world.


Выкинь свой телепатор, он не работает.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[45]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 03.01.18 23:21
Оценка:
Здравствуйте, ·, Вы писали:

·>Какая ещё очередь в таких условиях? Буфер, конечно. Ну поместили в буфер, а дальше что? Данные-то всё прут и прут. Или у тебя буфер размером 5Tb?


Если писать данные на диск сразу по много блоков, то они пишутся намного быстрее, чем при random write Q1. Ну а если скорости диска не хватает, то остается только развести руками и кричать "караул", больше ты здесь сделать ничего не можешь.

·>И как из буфера читатели будут читать?


Прямо вопрос на миллион. Вероятно, найти нужный блок и читать?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[23]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 03.01.18 23:31
Оценка:
Здравствуйте, netch80, Вы писали:

N>и всё это со входными потоками гигабиты в секунду на одну установку.


"Гигабиты" звучит очень круто и внушительно. А если перевести в байты, то это всего лишь сотня — другая мегабайт.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[7]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 03.01.18 23:31
Оценка:
Здравствуйте, netch80, Вы писали:

N>Если это явные противоречия, они должны вскрыться на этапе анализа ТЗ.


Ну если только в стране розовых единорогов.

N>Чего это?


Ну дык если их пишут специалисты более низкой квалификации. Что-то не проверили, а где-то false negatives насажали.

N>Но против плавающих ошибок и они не очень полезны, если дополнительно не снабжаются методиками поиска именно таких ошибок.


Я обычно гоняю их по несколько штук за раз (что создает дополнительную рандомизацию задержек) в цикле пока что-нибудь не сломается.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[31]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 03.01.18 23:31
Оценка:
Здравствуйте, itslave, Вы писали:

I>Угу, куда ни посмотри — всюду злые манагеры, которые спят и видят ка кнарастить себе команды. Не дают развернуться гениям-одиночкам, скорее всего самоучкам.


Не лопни, забрызгаешь.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[24]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.01.18 07:44
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

N>>и всё это со входными потоками гигабиты в секунду на одну установку.

CM>"Гигабиты" звучит очень круто и внушительно. А если перевести в байты, то это всего лишь сотня — другая мегабайт.

"Не лопни, забрызгаешь." ((c) некто CoderMonkey)
Полная подписка будет выше 20Gbit/s. И так безжалостно урезаем.
The God is real, unless declared integer.
Re[8]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.01.18 07:53
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

N>>Если это явные противоречия, они должны вскрыться на этапе анализа ТЗ.

CM>Ну если только в стране розовых единорогов.

Если на вашей планете разрешают и дают время думать только в стране розовых единорогов — ok, принимается.
Но я вообще-то говорил "должны", а не "должны были" или просто "вскрываются".

Другой вопрос, что для некоторых задач глубокий анализ ТЗ неотделим от написания кода. Из часто обсуждаемых это, например, компиляторы. Но такое пишет дай бог чтобы 0.1% от присутствующих здесь. У остальных значительно меньше плотность побочных эффектов любой спецификации.

N>>Чего это?


CM>Ну дык если их пишут специалисты более низкой квалификации. Что-то не проверили, а где-то false negatives насажали.


Позиция понятна, но я не хочу поддерживать, что низкая квалификация автоматически означает низкую ответственность.

N>>Но против плавающих ошибок и они не очень полезны, если дополнительно не снабжаются методиками поиска именно таких ошибок.

CM>Я обычно гоняю их по несколько штук за раз (что создает дополнительную рандомизацию задержек) в цикле пока что-нибудь не сломается.

Это тоже полезно, но откровенно мало. Relacy race detector имени remarkʼа выехал на том, что вводит задержки намеренно.
The God is real, unless declared integer.
Re[46]: Плюсы лучших методологий юнит тестирования.
От: · Великобритания  
Дата: 04.01.18 08:39
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>·>Какая ещё очередь в таких условиях? Буфер, конечно. Ну поместили в буфер, а дальше что? Данные-то всё прут и прут. Или у тебя буфер размером 5Tb?

CM>Если писать данные на диск сразу по много блоков, то они пишутся намного быстрее, чем при random write Q1. Ну а если скорости диска не хватает, то остается только развести руками и кричать "караул", больше ты здесь сделать ничего не можешь.
Что значит "быстрее"? throughput или latency? Если файловая операция будет больше нескольких миллисекунд, то входной сетевой буфер переполнится в самый неподходящий момент (пик нагрузки) и придётся делать redeliver — что только усугубляет ситуацию.

CM>·>И как из буфера читатели будут читать?

CM>Прямо вопрос на миллион. Вероятно, найти нужный блок и читать?
Блок в буфере или в файле? Ты путаешься уже.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[47]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 16:58
Оценка:
Здравствуйте, ·, Вы писали:

·>Что значит "быстрее"? throughput или latency? Если файловая операция будет больше нескольких миллисекунд, то входной сетевой буфер переполнится в самый неподходящий момент (пик нагрузки) и придётся делать redeliver — что только усугубляет ситуацию.


Вот так за несколько миллисекунд и сразу переполнится? Путаешься в показаниях.

·>Блок в буфере или в файле? Ты путаешься уже.


Сначала в одном, потом в другом. Можно начинать одновременно, чтобы было быстрее. Кэш обычно делается именно так
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[25]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 16:58
Оценка:
Здравствуйте, netch80, Вы писали:

N>Полная подписка будет выше 20Gbit/s. И так безжалостно урезаем.


То есть, на самом деле 2.5 гигабайта в секунду. Это уже не так мелко, но всё равно легко укладывается в RAID, и даже можно обойтись без кластера. А шуму то было
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[9]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 16:58
Оценка:
Здравствуйте, netch80, Вы писали:

N>Если на вашей планете разрешают и дают время думать только в стране розовых единорогов — ok, принимается.

N>Но я вообще-то говорил "должны", а не "должны были" или просто "вскрываются".

BDUF не работает. Никогда.

N>Позиция понятна, но я не хочу поддерживать, что низкая квалификация автоматически означает низкую ответственность.


Хоть какая там ответственность, но если писатель тестов чего-то не понимает, то он это не понимает.

N>Это тоже полезно, но откровенно мало. Relacy race detector имени remark?а выехал на том, что вводит задержки намеренно.


Красиво в теории, практически никто не использует на практике. Вероятно, для этого есть весомые причины.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[49]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 17:50
Оценка:
Здравствуйте, ·, Вы писали:

·>Я так тебя понял, что ты предложил вначале помещать быстро в некую очередь (точнее буфер), а потом "много блоков" скидывать в файл, т.к. "быстрее" (ты так и не ответил что это значит).


Быстрее и в плане latency, и в плане throughput.

·>Сколько именно и почему?


Почему бы тебе не ознакомиться с теорией, для начала?

·>В буфере нет индексов. И веселуха начнётся при многопоточном доступе.


В кэше будет всё, что ты сделаешь.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[51]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 18:42
Оценка:
Здравствуйте, ·, Вы писали:

·>Писать большими блоками не может быть лучше в плане latency.


Это ты так думаешь, потому что не понимаешь, как работает железо.

·>Т.е. "1e-8 секунд ... поместить данные в асинхронную очередь" у тебя ВНЕЗАПНО превратилось в кеш с блекждеком синхронизацией и индексами. Понятно откуда у тебя "ошибки в ТЗ".


Ну так и о требовании минимальной латентности при чтении ты тоже изначально ни словом не заикнулся. Так что да, ошибки в ТЗ. Ну или ты просто придумал это на ходу, чтобы твоя задача посложнее казалась
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[27]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 20:44
Оценка:
Здравствуйте, netch80, Вы писали:

N>А данные надо не просто записать на диск, а переработать и проиндексировать.


Это уже больше похоже на нормальную задачу
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[10]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.01.18 20:47
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

N>>Если на вашей планете разрешают и дают время думать только в стране розовых единорогов — ok, принимается.

N>>Но я вообще-то говорил "должны", а не "должны были" или просто "вскрываются".

CM>BDUF не работает. Никогда.


Не буду вступать в спор по этому поводу, но BDUF и не предлагался. То, что ты не понимаешь разницы, очень показательно.

N>>Позиция понятна, но я не хочу поддерживать, что низкая квалификация автоматически означает низкую ответственность.

CM>Хоть какая там ответственность, но если писатель тестов чего-то не понимает, то он это не понимает.

Это не помешает написать тесты согласно текущему ТЗ.

N>>Это тоже полезно, но откровенно мало. Relacy race detector имени remark?а выехал на том, что вводит задержки намеренно.

CM>Красиво в теории, практически никто не использует на практике. Вероятно, для этого есть весомые причины.

Ссылки на "[практически] никто не использует" — в студию.
The God is real, unless declared integer.
Re[29]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 21:00
Оценка:
Здравствуйте, netch80, Вы писали:

N>Ну я вообще-то сказал об этом с самого начала. Даже с учётом относительно лёгкой переработки тут уже есть над чем хорошо подумать.


Не то чтобы "хорошо подумать", просто нормальный уровень.

N>Для дополнительного устрашения сообщу, что данные поступают обычно по UDP multicast, перезапросы невозможны.


А почему это плохо?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[11]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 21:04
Оценка:
Здравствуйте, netch80, Вы писали:

N>Не буду вступать в спор по этому поводу, но BDUF и не предлагался. То, что ты не понимаешь разницы, очень показательно.


Предусмотреть все возможные ошибки, неточности и противоречия еще при планировании и написании ТЗ — это как раз чистейший BDUF. А он не работает.

N>Это не помешает написать тесты согласно текущему ТЗ.


Полезность которых будет равна нулю из-за ошибок на верхнем уровне, а потом их придется еще и переписывать.

N>Ссылки на "[практически] никто не использует" — в студию.


Не, логика так не работает. Это ты доказывай, что его на самом деле используют.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[30]: Плюсы лучших методологий юнит тестирования.
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.01.18 21:09
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

N>>Ну я вообще-то сказал об этом с самого начала. Даже с учётом относительно лёгкой переработки тут уже есть над чем хорошо подумать.


CM>Не то чтобы "хорошо подумать", просто нормальный уровень.


С "просто нормальным" можно тупо не успеть по процессору.
Как-то защищает очень жёсткое разделение активности по ядрам процессоров, спецдрайвера сетевух и т.п.

N>>Для дополнительного устрашения сообщу, что данные поступают обычно по UDP multicast, перезапросы невозможны.

CM>А почему это плохо?

Чуть не успел — потерял часть данных. Соответственно анализ уже будет с дефектами.
The God is real, unless declared integer.
Re[31]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 21:12
Оценка:
Здравствуйте, netch80, Вы писали:

N>С "просто нормальным" можно тупо не успеть по процессору.

N>Как-то защищает очень жёсткое разделение активности по ядрам процессоров, спецдрайвера сетевух и т.п.

Ну или можно просто не жлобиться на железе.

N>Чуть не успел — потерял часть данных. Соответственно анализ уже будет с дефектами.


Очередь для обработки, естественно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[33]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 21:48
Оценка:
Здравствуйте, netch80, Вы писали:

CM>>Очередь для обработки, естественно.

N>То же самое.

А в чем проблема, собственно?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[13]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 04.01.18 21:48
Оценка:
Здравствуйте, netch80, Вы писали:

N>Вот именно что ты путаешь чисто внутренние противоречия ТЗ и его адекватность внешней задаче.


Объясни.

N>Да. Но в дальнем плане не отличается от изменения задачи из-за неизбежного изменения внешних условий.


Только переписывать намного больше.

N>Именно так и работает. Я просто его упомянул, а ты сказал, что его не используют.


Если проект есть, но в реальной практике бесполезен — значит, можно было и не упоминать.

N>Доказывай.


Ну я ж не ты, могу и доказать
https://groups.google.com/forum/#!forum/relacy
70 топиков за 10 лет, из них больше половины написано одним и тем же чуваком. На этом вопрос о практической используемости данного проекта можно закрыть.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[2]: Плюсы лучших методологий юнит тестирования.
От: student__  
Дата: 05.01.18 11:46
Оценка:
Здравствуйте, CoderMonkey, Вы писали:
CM>Я ограничиваюсь интеграционными тестами, юнит тесты — только для сложных алгоритмов.
CM>А тэорэтики пусть идут лесом.
А если интеграционные тесты не автоматизированы, а сам процесс интеграции и интеграционного тестирования многоступенчатый, занимает много времени и согласования с N коллегами, разбросанными по разным городам и весям (и странам), где N > 2?

Как вы докажете, что в очередном цикле релиза ваша часть системы не валит весь продукт?
И что интеграторам вообще имеет смысл тратить время на то, что заведомо бажно, и застопорит работу над всем проектом, пока либо интеграторы не откатят ваши изменения, либо пока вы не почините их сами?
Или вы сразу 100% багфри код будете писать?
Re[34]: Плюсы лучших методологий юнит тестирования.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.01.18 14:05
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>>>Очередь для обработки, естественно.

N>>То же самое.

CM>А в чем проблема, собственно?


А что, очередь ускорит процессор?
Re[3]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 05.01.18 16:58
Оценка:
Здравствуйте, student__, Вы писали:

__>А если интеграционные тесты не автоматизированы, а сам процесс интеграции и интеграционного тестирования многоступенчатый, занимает много времени и согласования с N коллегами, разбросанными по разным городам и весям (и странам), где N > 2?


Плохо, значит. Очень плохо.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[35]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 05.01.18 16:58
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>А что, очередь ускорит процессор?


Нет, но она 1) не будет подолгу блокировать коллбеки от сетевого стека, что уменьшает вероятность потери данных 2) позволит передавать часть данных для обработки на другой компьютер, в любой удобной тебе форме
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[4]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 05.01.18 17:00
Оценка:
Здравствуйте, itslave, Вы писали:

I>Интернет бойцы, они такие.


На себя посмотри, родной. Вообще ни слова по делу не написал, только зубоскалишь и бахвалишься.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[6]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 05.01.18 17:40
Оценка:
Здравствуйте, itslave, Вы писали:

I>По делу я писал


Покажи пример.

I>пока ты топик флудом не забил про свою немерянную крутизну


Ну-ка ну-ка. Где, например?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[8]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 05.01.18 18:12
Оценка:
Здравствуйте, itslave, Вы писали:

I>Цитаты нет — слив засчитан, балаболка.


Лексикон базарной бабки, что тут еще можно добавить

I>http://rsdn.org/forum/flame.comp/7004312.1
Автор: itslave
Дата: 26.12.17


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

I>http://rsdn.org/forum/flame.comp/7005777.1
Автор: CoderMonkey
Дата: 28.12.17


Есть некоторая разница между "некоторые прогеры мало чего умеют" и "я невероятно крутой", тебе так не кажется?
Это к вопросу о логике.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[10]: Плюсы лучших методологий юнит тестирования.
От: CoderMonkey  
Дата: 09.01.18 16:55
Оценка:
Здравствуйте, itslave, Вы писали:

I>Трололо, такое трололо...


Я вижу.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re: Плюсы лучших методологий юнит тестирования.
От: elmal  
Дата: 11.01.18 07:56
Оценка:
Здравствуйте, UberPsychoSvin, Вы писали:

UPS>А в чём плюсы?

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