Если мы удаляем тесты, которые слишком просты для повреждения во время TDD

Вы говорите, что это слишком просто, чтобы потерпеть неудачу:

for (i = 0; i < observers.length; ++i) {
    // Notify observer observers[i]
}

Заманчиво так думать, но примите во внимание эту распространенную ошибку:

for (i = 0; i <= observers.length; ++i) {
    // Notify observer observers[i]
}

Или эту:

for (i = 0; i < observers.length; ++j) {
    // Notify observer observers[i]
}

Или возможно, наблюдатели добавляются неправильно. Или ... или ... или ...

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

Да; Если вы тестируете функциональность базового компилятора / виртуальной машины, ваш тест будет слишком простым. Если, конечно, вы не доверяете той конкретной части компилятора / виртуальной машины, которая выполняется.

Но, конечно, реальность тестов немного сложнее, чем просто ответ «да / нет» на этот вопрос. Как отмечено в другом ответе, если вы уже написали тесты, не удаляйте их. Но вы также не должны использовать их в контексте покрытия кода в качестве аргумента в пользу уверенности.

Нет.

Вы делаете это совершенно правильно: сначала пишете тесты, которые терпят неудачу, а затем исправляете их. Оставьте эти тесты в покое, напишите более сложные в будущем, если вы думаете, что они вам понадобятся (например, для воспроизведения ошибок).

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

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

Использование функции mmap () ограничено системным значением QSHRMEMCTL. Если это системное значение равно 0, функция mmap () не может создавать совместное отображение с PROT_WRITE возможностью. По существу, это предотвращает создание карты памяти, которая может изменить содержимое отображаемого файла потока. Если параметр flags указан MAP_SHARED, параметр prot указывает PROT_WRITE, а системное значение QSHRMEMCTL равно 0, то функции mmap () завершатся ошибкой, и количество ошибок в результатах EACCES.

Идея добавления атрибута InternityVisibleTo является хорошей, но я думаю, что проблема заключается в том, что Xml-код сериализации ищет только открытые типы в сборке.
Насколько мне известно, нет пути сериализовать или десериализовать внутренние типы, и вам придется либо объявить типы общедоступными, либо написать свой собственный код сериализации.
Более того, в документации по классам GroupSerializer явным образом указано, что сериализуются только общедоступные свойства объекта: «сериализация XML - это процесс преобразования общедоступных свойств и полей объекта в последовательный формат (в данном случае XML) для места хранения или транспорта», так что это действительно выглядит как конструкторское решение.

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

Однако в будущем вы можете написать только один неуспешный тест. (См. Три правила ). Это потому, что это позволит улучшить дизайн во время разработки кода.

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

Я также подозреваю, что у вас было непростое время для реализации вашего кода, поскольку каждый шаг реализации мог пробить больше тестов, чем прошел, но эй, я только догадываюсь!