2013-07-28 1 views
0

Я пишу драгоценный камень, чтобы обернуть RubyGem xmpp4r. Я хочу добавить тесты для всего, что могу, но я новичок в тестировании и немного застрял здесь.Как протестировать, казалось бы, «непроверяемый» в Ruby-коде?

По сути, я хочу, чтобы один из моих классов имел функцию «connect», но я понятия не имею, как это проверить ... все примеры, которые я могу найти в Интернете по тестированию, чрезмерно упрощены. это «зеленая брокколи» и т. д., вы получаете эту идею.

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

РЕДАКТИРОВАТЬ: Возможно ли пройти тест, если он не встретит каких-либо исключений? Если бы я был на правильном пути, выполнив это?

ответ

2

Просто помните, что вы, как программист, являетесь лордом своего собственного мира кода.

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

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

Попробуйте сделать TDD (Test Driven Development), и вы получите мое мнение.

Также имейте в виду, существуют различные виды тестирования: Функциональное тестирование/High Level тест Unit/Низкий уровень UAT/User Acceptance Testing Тестирование производительности Исследовательское тестирование/тестирование рук Интеграционное тестирование (вы можете создать некоторые макеты частей, которые вы кодируете, будут работать, чтобы предвидеть какие-либо проблемы до интеграции)

Тестирование стоит дорого, поэтому не стоит проверять, что все идет о тестировании, что нужно протестировать.

Даже НАСА не проверяют «все»

тестирование ... глубоко как программирование. Хорошее погружение!

http://en.wikipedia.org/wiki/Software_testability

+0

Мне нравится ваш стиль общего обзора.В то время как я искал более направленных советов, ваш ответ был очень информативным, и я определенно принимаю во внимание то, что вы опубликовали. Спасибо за ваше время и усилия, чтобы сделать его более понятным для меня! –

2

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

т.е.

xmpp4r.should_receive(:connect).and_return(mock("xmpp4r")) 

Если камень не испытывается, это примерно так же, как вы не имели каких-либо тестов сами. Вы должны рассмотреть возможность использования другого драгоценного камня или тестирования его самостоятельно (или даже создать его с помощью TDD).

+0

Это было очень кратким и точным, и хотя я читал это раньше, это проскользнуло, так что это хорошее напоминание об этом аспекте всего. Большое спасибо! –