Взятие поблочного тестирования к следующему уровню
Комментарии полезны, потому что они успокаивают человека, читающего ваш код - возможно, «будущее вас» - что вы думали о ее благополучии.
5 ответов
TDD and BDD aren't meant to be tools to measure code quality, they are meant to be tools to aid in designing loosely coupled, highly-maintainable pieces of code. It has more to do about API design than anything else. It's meant to ensure that the code does what it says it does, and does it in a way where changing one part of the code does not affect other parts.
I would expect that your feeling of exasperation with BDD arises from the expectation that you're writing tools to simply "eliminate bugs" or "replace your QA process", both of which neither BDD nor TDD are meant to do. Test Driven Development means "development, driven by tests", and not "tests, driven by development". It appears to me that you want the latter.
Integration testing and software quality assurance are totally different topics, but I understand the reasons behind the massive confusion between these and associating TDD with them.
Test Driven Development means "development, driven by tests", and not "tests, driven by development". It appears to me that you want the latter.
Update Just want to share my blog entry regarding this issue: Repeat after me: Test Driven Development is about design, NOT testing!
Unit Testing is just one type of testing, it is not the only type of testing.
Unit Testing is supposed to cover the smallest possible unit of work possible, mocking out all dependencies is a very crucial process to achieve this goal, giving that these dependencies have their own unit tests that covers them.
After you cover a decent amount of your small units, you then make what is called Functional Test, which looks like Unit Test however it doesn't mock all the stuff you are mocking in a unit test, generally if your system built by different teams, Functional Tests mocks only the dependencies introduced by other teams, but you team code is not mocked.
After you cover Functional test, you will have the Integration Tests, and here when you start using real dependencies from other teams, in general you shouldn't have any mocking in this kind of tests.
Given the fact that all three types of tests are built using mstest or NUnit, it is still code test.
Я нахожусь на той же дороге, что и вы. Для меня книга, которая стала моей Библией модульного тестирования, - это xUnit Test Patterns - Refactoring Test Code Джерарда Месароса.
Ознакомьтесь с" Конструированием объектно-ориентированного программного обеспечения "Бертрана Майера.
Концепция называется" Разработка, управляемая контрактом ". Это поточный тип тестирования на на уровне функций, это изменило способ программирования.
Если вы используете CDD в Eiffel, языке, также написанном Бертраном, они автоматически проверяются средой выполнения на этапе тестирования и отладки.
Если вы действительно следуете TDD, как описано практиками, каждый тест должен тестировать относительно небольшую часть вашего кода (всего несколько строк). По определению, это не интеграционные тесты. Ребята из TDD скажут вам, что вам нужен целый отдельный набор тестов для выполнения интеграционного тестирования.
Вы правы в том, что такой набор тестов TDD может в конечном итоге утомить вас в мелочах. Разработка, основанная на тестировании, по определению - это создание, проектирование и тестирование деревьев, а не лесов. TDD - это создание требований посредством модульных тестов, но по самой своей природе он воплощает требования на микроскопическом уровне.
Если, как утверждают специалисты TDD, вам нужны отдельные интеграционные тесты, тогда вам также потребуются требования, спецификации и процедуры для этих тестов.