Абсолютно верно написано. Тестовые методы не должны вызывать друга (за исключением инициатора и финализатора), но в одном тестовом методе могут вызываться разные метода тестируемого объекта. Тривиальный пример: в большинстве случаев нельзя протестировать метод класса, не вызвав предварительно его конструктор.
Если не секрет - почему не предлагать nbtstat? Создал процесс, переопределил поток вывода, процесс запускает cmd с вызовом nbtstat. С измененным потоком вывода не работает?
Перебор не пробовали? Собрать имена компов в сетке, и их IP просмотреть на совпадение с искомым?
Вложенные циклы ограниченно вкладываются. Два уровня вложения, три, четыре, число конечно и известно во время компиляции. Рекурсия раскручивается в теории бесконечно: её ограничивает лишь доступная память.
Суть - указатели на методы. Помогают вызывать методы в рантайме, например. Крайне полезны при разработке плагинов. Я иногда их использую при тестировании: создаю наследника тестируемого класса, переопределяю методы, заменяя логику вызовом делегата, если тот не null. В тестовых методах достаточно прописать необходимый метод делегату, чтоб тест спокойно проходил. В результате получается читаемый код.
Еще один пример - нужно вызвать метод в зависимости от выбранного значения в выпадающем списке. Можно сделать здоровеный case, а можно предзаполняемый словарик . Сам dropbox заполнить из словарика через DataSource, и методы вызывать через делегат.
Пусть modulo = остатку от деления n на 6. Пусть k= результат целочисленного деления n на 6. Короче, n = 6k + modulo.
IF modulo == 0: n = 6k = (6+6+6+...+6).
IF modulo == 1: n = 6k + 1 = 6(k-1) + 6 + 1 = 6(k-1) +7 = 6(k-1) + 5 + 2.
IF modul0 > 1: n = 6k+modulo.
Интересно. Если работать по первому варианту и пытаться добавить записи, то будут выскакивать ошибки. При этом, значения счетчика будут увеличиваться.
То есть, если я создал таблицу с ограничением {id, myInt}, id - счетчик, и добавляю
"insert into myTable values(12), (12)",
"insert into myTable values(7)",
в итоге добавится одна лишь запись (3,7).
Дмитрий Королёв: Тогда в чем проблема? Списки вопросов есть, на "официальные" ответы - плевать.
Возможно, Вам стоит поискать списки вопросов с краткими ответами (как "базовыми", так и "хитрыми"), что-то вроде шпаргалок. Только вот, детальное изучение подобного списка займет слишком много времени, да и ЦА (по факту, опытные разработчики, уже знающие особенности языка\платформы\фреймворка) слишком маленькая. Так что, вероятность успешного поиска и освоения довольно мала.
Дмитрий Королёв: Я в этом не уверен. Специфика тестов по программированию (да и по многим другим дисциплинам) - почти всегда на вопрос можно несколькими, казалось бы, противоположными способами. Например: "можно ли изменять readonly-поля в C#?" - "можно, если извратиться". Тесты составляются из расчета на стандартные ситуации, но вопрос, какую именно ситуацию считать стандартной - открыт. И это если автор не придумал ""вопрос с хитринкой".
По этой причине тесты я смотрю как список вопросов, ответы на которые стоит знать. Как их оценит система - в большинстве случаев не важно, важнее, как свои знания оценишь ты сам (разумеется, это не касается ЕГЭ, и тестов на том же upworks, если ты ищешь клиента).
Сергей Протько: Положим, мы пишем тесты. Надо много всего мокать. Мы начинаем рефакторинг. Тратим время на изменение системы. Поскольку рефакторить без тестов ненадежно и страшно - тратим много времени. Если повезет разбить рефакторируемый код на модули - еще ничего. Если же мы работаем с кодом, состоящим из спагетти - мы убьем кучу времени на фактическое переписывание модуля. Надо ли оно было - не факт.
"Необходимость покрывать тесты увеличивает потребность в соблюдении всяких принципов типа SOLID". Вы исходите из того, что соблюдение SOLID - благо. Если предположить, что SOLID не несут значимой пользы - мы вынуждены руководствоваться лишними принципами при разработке архитектуры\программы, что зло.
В целом, Ваш ответ достаточно точный. Не хватает лишь двух моментов: недостатков TDD и области применения методики. За фразу "(пусть и не на 100%, обычно хватает и 20% что бы можно было жить, все зависит от сроков жизни проекта и требуемого уровня надежности)" отдельный респект. Неофитам стоит высекать её в камне, чтоб запомнили.
otetz Спасибо за ссылку. К сожалению, под парсером я подразумеваю программу, которая просматривает диапазон страниц, выдирая с каждой из ник конкретные данные.
Эрвин Мартиросян: Не совсем полный. Заполняем пустую доску рекурсивно. Как только при добавлении доминошки сумма в одном из рядов\столбцов\диагоналей больше 6 - прекращаем исследование этой ветки.
Заранее составьте порядки, в которых будут укладываться доминошки (все вертикально, все горизонтально, и т.д.).
Перед заполнением очередной ячейки просчитайте суммы всех рядов\диагоналей\столбцов, на которые она повлияет. Проверяйте новые суммы лишь для этих рядов.
Не забудьте поворачивать доминошки в обе стороны.
Можно учитывать, что общая сумма цифр равна 6*4=24. Позволит быстро исключать доминошки из перебора. Выберите доминошки с минимальными весами. Полагаю, вариантов будет очень мало. :)
Евгений Елчев: Размеры файлов для данных машин выделяются? Объемы записей?
В принципе, у Вас уже есть костыльное решение: написать скрипт, который будет раз в n минут открывать этот файл в блокноте, и тут же процесс блокнота закрывать (плюс закинуть скрипт в автозагрузку).
"они утверждают, что проблема не в софте, а в системе" - на основании чего они делают такое заявление? Пока причина проблемы не выяснена, оно не может быть истинным.
Я уточню сценарий.
1. Запускается сервер. Что-то пишет в клиентский файл (на той же машине, что и сервер).
2. Запускается клиент. Подсоединяется к клиентскому файлу через сетевой диск, читает данные.
3. Сервер каждую секунду ищет обновления. Если нашел - дозаписывает их в файл.
4. Что именно делает клиент? Каждую секунду пытается считать новую строку? Как именно определяется, что файл доступен, а клиент не видит новые данные? Возможна ли ситуация, когда новые данные пришли, клиент их не прочитал, и без выключения клиента можно открыть файл в блокноте и увидеть новые данные?
Евгений Елчев: Точно! Потери пакетов! Столкнулся с подобным разик, когда в нашей транспортной проге начали отваливаться узлы. Клиенты начали отваливаться с ростом числа соединений и нагрузки. Проблема была в том, что отклик от сервера шел дольше разрешенного времени.
Железно помогали перезапуск клиентов\сервера и снижение максимального размера передаваемых файлов.