Как создать хорошее покрытие кода логики с плавающей запятой?

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

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

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

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

Вы упомянули выше, что работаете с числовым интенсивным кодом - возможно, стоит протестировать уровень выше, чтобы вы могли протестировать поведение в системе, которую вы ищете, а не просто обрабатывать числа - предполагая, что код не является чисто числовым, это будет помочь вам установить некоторые реальные условия выполнения, а также убедиться, что все, что на самом деле делает бит обработки чисел, взаимодействует с остальной частью программы так, как вам нужно - если это что-то алгоритмическое, вам, вероятно, лучше написать приемочный тест язык, чтобы помочь охарактеризовать желаемые результаты в различных ситуациях - это дает четкое представление о том, чего вы пытаетесь достичь, а также позволяет вам пропускать большие объемы (реальных) данных через систему, которая, вероятно, лучше, чем сгенерированная компьютером Вход. Другим преимуществом этого является то, что если вы понимаете, что алгоритм нуждается в радикальной переработке, чтобы соответствовать некоторым новым требованиям, все, что вам нужно сделать, это добавить новый тестовый пример, а затем переписать/рефакторить; если бы ваши тесты просто рассматривали детали алгоритма и предполагали влияние на внешний мир, тогда у вас была бы существенная головная боль, пытаясь выяснить, как алгоритм в настоящее время влияет на поведение, какие части были правильными, а какие нет, а затем пытаясь перенести множество модульных тестов на новый API/алгоритм.