Закрытые методы называет открытый метод, таким образом, исходные данные к Вашим открытым методам должны также протестировать закрытые методы, которые называют те открытые методы. Когда открытый метод перестал работать, тогда это могло быть отказом в закрытом методе.
Хорошее соотношение теста и кода - это такой тест, который позволяет вам чувствовать себя уверенно в написанном вами коде, а также позволяет вам с уверенностью провести рефакторинг: вы будете знать, в какой области вы испытываете проблемы в остальной части вашего кода. заявление. У меня было тестовое соотношение от 1: 1,5 до 1: 2,5 или около того, оно действительно может варьироваться в зависимости от сложности вашего приложения.
Отношение кода к тесту - это немного вводящая в заблуждение статистика. Намного лучший метод - использовать rcov
, вы можете легко использовать его, запустив rake spec: rcov
Хотя 100% покрытие кода иногда рассматривается как абсолютная цель, вы быстро сталкиваетесь с закон убывающей доходности . Лично я стремлюсь к охвату кода 90% всего производственного кода; хотя в основном это произвольно, мне гораздо проще иметь целевое число, к которому можно стремиться.
Это варьируется. Простой код Я ожидал бы столько же тестового кода, сколько производственного кода. Сложный код легко заслуживает вдвое большего количества тестового кода. Занимайтесь разработкой через тестирование, и вам не придется беспокоиться о соотношении, поскольку все в коде было проверено тестом, и это то, что важно.
В данный момент мы говорим о мнениях. Хорошее соотношение кода и тестирования - это такое соотношение, при котором ваш код покрыт настолько, насколько это необходимо, чтобы обеспечить как уверенность в написанном, так и уверенность в том, что при рефакторинге вы будете знать, что ломается вокруг вас.
Цифры - это хорошо, но слишком много их может быть опасно.
Моя цель - это не непроверенный код, раскрытый rcov и heckle. Когда вы получите все покрытие, которое можно получить с помощью rcov, то сможете прогнать код через heckle. Heckle модифицирует ваш код и показывает, какие модификации не были пойманы тестами.
rspec знает о heckle. После установки "жемчужины хекле": "spec foo_spec.rb -H Foo". О, и если вы получите причудливую ошибку, установите версию 1.2.2 из ruby2ruby вместо 1.2.4.
Here's heckle жалуется на функцию, которую, как я думал, я полностью определил:
The following mutations didn't cause test failures:
--- original
+++ mutation
def model_matches?(substring)
- s = substring.gsub(/\./, ".")
+ s = substring.gsub(/\033!\032\002l\}\?V\010d\}\r\-\fyg,a\*jFT\003_"ga\016\020ufN\0066/, ".")
s = substring.gsub(/\*/, ".*")
s = "^#{s}$"
Regexp.new(s, "i").=~(@model)
end
--- original
+++ mutation
def model_matches?(substring)
- s = substring.gsub(/\./, ".")
+ s = substring.gsub(/\./, "\023GA3w+h-#z$?I;a\"k0n^r$\005io#l\023H1M{\034m")
s = substring.gsub(/\*/, ".*")
s = "^#{s}$"
Regexp.new(s, "i").=~(@model)
end
--- original
+++ mutation
def model_matches?(substring)
- s = substring.gsub(/\./, ".")
+ s = nil
s = substring.gsub(/\*/, ".*")
s = "^#{s}$"
Regexp.new(s, "i").=~(@model)
end
--- original
+++ mutation
def model_matches?(substring)
s = substring.gsub(/\./, ".")
s = substring.gsub(/\*/, ".*")
s = "^#{s}$"
- Regexp.new(s, "i").=~(@model)
+ Regexp.new(s, "v\022").=~(@model)
end
How cool is that?
Единственное, что я нашел, что действительно сложно получить полное тестовое покрытие, это тесты, включающие параллельность, в том числе и условия гонки. Пытаться доказать, что мьютекс или критическая секция должны быть на месте, может быть сложно. Иногда это можно сделать. Иногда приходится просто пожимать плечами, ставить строку кода, который не умеешь тестировать, и двигаться дальше
.