Зачем реализовывать свой Singleton если можно воспользоваться встроенным DI контейнером?
Просто в методе ConfigureServices класса Startup добавляете singleton вашего counter
services.AddSingleton<ICounter, Counter>();
И теперь можете получать ICounter как зависимость через конструктор контроллера например.
Ну изначально мне не понятно было, почему сценарное тестирования исключает исследовательское. Прохождение сценария — это не цель, а средство проверки качества системы. И да, я считаю, что если для маленьких систем можно обойтись только исследовательским тестированием, то для больших систем, сценарий в том или ином виде, с каким-либо уровнем детализации, необходим.
Вы не можете проводить исследовательское тестирование при регрессионном тестировании большой и сложной системы большой командой. Очень велик шанс, что какие то сценарии работы не будут протестированы. Но с другой стороны, вы не можете проходить только сценарий, из-за этого велик шанс, что вы пропустите ошибки при вариантах работы системы, которые не были учтены при составлении сценария. Поэтому, сейчас происходит как. У тестировщика есть сценарий, который он обязан пройти, этот сценарий, соответствует тому, как пользователи будут работать с системой, но при прохождении сценария, тестировщик может так же «попутно» проверить другие сценарии работы на свое усмотрение, вводить некорректные данные и многое другое. К тому же, когда систем много, то тестировщик может не знать всех ньюансов работы с системой, тогда ему тоже необходим сценарий.
Почему автор считает, что при подробном сценарном тестировании, тестировщик не занимается и отчасти исследовательским? Мне кажется, автор считает, что цель тестировщика при сценарном тестировании — пройти сценарий, но это не так, так же как и в исследовательском тестировании целью является проверка, что система работает так, как ожидалось и поиск ошибок. Да, у тестировщика есть сценарий, который как правило описывают возможные сценарии работы пользователя с системой, и тестировщик обязан проверить, что такой сценарий выполняется, но при этом тестировщик так же может производить проверки и не описанные в сценарии.
Почему тест таймингов должен основываться на статистике? Тест таймингов должен основываться на требованиях к системе, а вот требования к системе могут основываться на статистике. Например у вас в интернет магазине кнопка добавления товара в корзину стала отрабатывать на 20 секунд дольше и продажи уменьшились на 80%. Уже проведено бесчисленное количество исследований по производительности пользовательских интерфейсов. Практика показывает, что лучше это не игнорировать. По сути вы предлагаете проверить, что все работает, а я предлагаю проверить, что все работает и работает хорошо.
Как я и писал выше, вы сами управляете выбором констант и можете выбрать максимально комфортные, которые будут отвечать вашим критериям стабильности. В посте у wait точно также захардкожена константа 20000. Cуть в том, что массово изменить эту константу для тестирования на менее производительном стенду не получится. Неоднозночность, даже в селениум тестах должна быть минимальной. Не плохо, когда тест падает и ошибки анализируются. Плохо, когда тесты не падают, но ошибки и неопределенно поведение происходит уже у пользователя. Вообще тайминги это некоторый контракт между тестировщиком и пользователем «Я гарантирую, что при таких условиях элемент отработает за такое время». Если вы не готовы гарантировать 1 секунду, вы можете гарантировать 100 секунд. Так или иначе используя подход указанный в посте вы тайминг пропишите, но вопрос в том, как этим таймингом вы будете управлять в дальнейшем.
Если разработчик увеличит время анимации случайно, то тест упадет и разработчик исправит время анимации в приложении. Если разработчик увеличит время анимации специально, то тест упадет и разработчик исправит время анимации в тесте. Изменились требования — изменились тесты, которые эти требования проверяют. Мне кажется, что это как раз обязанность теста. По поводу увеличения констант — их не нужно увеличивать, нужно выбирать другую, они на то и константы. Если у нас элемент стал работать дольше чем «быстро», значит нам нужно или определить почему он стал работать не «быстро» или перевести в категорию «нормально» то есть изменить требования для элемента. И только в крайнем случае нужно пересмотреть выбранные константы для выбранной платформы.
Да, но в данном случае вы говорите не «анимация должна выполняться 800 миллисекунд», а «анимация должна выполняться не более 800 миллисекунд» то есть не зависимо от того в какой среде выполняется тест, анимация должна выполняться не больше указанного времени. Все таки в большинстве случаев мы не знаем насколько загружена может быть машина пользователя, но не хотелось бы, чтобы у пользователя все работало как и задумывалось. Ну и никто не запрещал устанавливать пороговые значения в зависимости от платформы.
Мне не совсем понятно, почему анимация, которая должна отрабатывать за 800 миллисекунд, вдруг начала отрабатывать за 1200 миллисекунд и это не ошибка. Я конечно соглашусь, что писать driver.sleep(800) не хорошо, хотя бы потому, что тут захардкожена константа. Вторая проблема в том, что если у вас браузер все сделал за 200 миллисекунд, то остальные 600 миллисекунд будет просто ждать. Соглашусь, что wait с таймаутом это куда лучше, но то, что в wait так же хардкодятся константы, наверное не хорошо, по мне так лучше эти константы оговорить заранее для всего проекта и вынести в отдельное место, например:
let iframeElem = driver.wait(
until.elementLocated(By.className('result-iframe')),
speed.slow
);
В таком случае если скорость работы элемента не укладывается в пороговые значения, вы будете анализировать причину почему так случилось и нужно ли элемент из разряда slow переводить в verySlow или же нужно как-то оптимизировать его работу?
Как можно получить доступ к контролам извне? Отрисовать интерфейс мало, его еще нужно как то тестировать. Если для браузеров есть web driver, для WPF есть Automation UI. Как программно взаимодействовать с интерфейсом написанном при помощи данной библиотеки?
Именно так, специализированный майнер работает в 1000 раз лучше, поэтому майнить биткоин на видеокартах перестали в конце 2013 начале 2014 года. С другой стороны, появились другие криптовалюты с другими алгоритмами шифрования для которых ASIC создать сложнее. Например ZCash на видеокартах сейчас майнят в основном его или эфир, но второй в скором времени будет майниться по другому принципу. Не стоит думать, что майнинг — это деньги из воздуха, с таким же успехом можно сказать, что аренда квартир — это деньги из воздуха. Про майнинг на мобильных устройствах это тоже, что и перевозить бетон для строительства небоскреба на Lamborghini Gallardo — как бы можно, но зачем?
Осталось только убедить 1 миллиард людей установить приложение, которое будет разряжать у них батарею с максимально возможной для телефона скоростью, за что они будут получать 2 копейки в 10 лет.
Очень странно видеть на этом сайте статью от человека, который абсолютно не разобрался в теме.
Давайте начнем с того, что даже если вы будете использовать самую мощную видеокарту — вы ничего не заработаете на майнинге биткоин. Все из-за того, что биткоин полностью захватили ASIC
Главная характеристика при майнинге — это H/s (Количество хешей в секунду) Какой процент от общего количества H/s всей сети вы будете производить, такой процент от эмиссии биткоинов вы будете получать, то есть чем больше у вас вычислительная мощность, тем больше вы получаете.
А теперь о величинах:
Общая вычислительная мощность сети — 7 000 000 TH/s вот статистика
Мощность ASIC Antminer S9 стоимостью 4000 фунтов — 13.5 TH/s
Мощность Nvidia GTX 1080Ti даже найти сложно, так как нецелесобразно
Мощность Nvidia GTX 980 — 1,1 GH/s (в 10 000 раз меньше чем ASIC)
Мощность PS3 (о которой говорится в статье) — 13 MH/s
Мощность телефонов в пределах 1 MH/s
Эмиссия — примерно 13 BTC в 10 минут
Теперь вы можете легко посчитать ваш доход за 10 минут по формуле:
13 * ваша мощность /Общая мощность сети
Для Nvidia GTX 980 — (13 * 1.1 * 10^9) / (7 * 10^18) = 2.04 * 10^-9
по текущему курсу 1BTC = 4600$ вы получите примерно 0.0000094$ за 10 минут.
Учтите, что тут не учтена стоимость видеокарты и стоимость потребляемой электроэнергии.
Остальное можете посчитать сами.
Зачем реализовывать свой Singleton если можно воспользоваться встроенным DI контейнером?
Просто в методе
ConfigureServicesклассаStartupдобавляете singleton вашегоcounterИ теперь можете получать
ICounterкак зависимость через конструктор контроллера например.speed.veryFast= 100;
speed.fast = 300;
speed.normal = 1000;
speed.slow = 10 * 1000;
speed.verySlow = 100 * 1000;
И в wait уже использовать эти константы:
В таком случае если скорость работы элемента не укладывается в пороговые значения, вы будете анализировать причину почему так случилось и нужно ли элемент из разряда slow переводить в verySlow или же нужно как-то оптимизировать его работу?
Давайте начнем с того, что даже если вы будете использовать самую мощную видеокарту — вы ничего не заработаете на майнинге биткоин. Все из-за того, что биткоин полностью захватили ASIC
Главная характеристика при майнинге — это H/s (Количество хешей в секунду) Какой процент от общего количества H/s всей сети вы будете производить, такой процент от эмиссии биткоинов вы будете получать, то есть чем больше у вас вычислительная мощность, тем больше вы получаете.
А теперь о величинах:
Общая вычислительная мощность сети — 7 000 000 TH/s вот статистика
Мощность ASIC Antminer S9 стоимостью 4000 фунтов — 13.5 TH/s
Мощность Nvidia GTX 1080Ti даже найти сложно, так как нецелесобразно
Мощность Nvidia GTX 980 — 1,1 GH/s (в 10 000 раз меньше чем ASIC)
Мощность PS3 (о которой говорится в статье) — 13 MH/s
Мощность телефонов в пределах 1 MH/s
Эмиссия — примерно 13 BTC в 10 минут
Теперь вы можете легко посчитать ваш доход за 10 минут по формуле:
13 * ваша мощность /Общая мощность сети
Для Nvidia GTX 980 — (13 * 1.1 * 10^9) / (7 * 10^18) = 2.04 * 10^-9
по текущему курсу 1BTC = 4600$ вы получите примерно 0.0000094$ за 10 минут.
Учтите, что тут не учтена стоимость видеокарты и стоимость потребляемой электроэнергии.
Остальное можете посчитать сами.