привет.
Вопрос немного философский конечно, но у кого есть мысли по сабжу ... буду рад услышать.
Тема такая - тестирование.
Пишется код (client side) на JS. пишется в форме модуля. 
Ессно, это не реально код приложения, а пример поясняющий проблему.
Если бы не было тестов, было бы грубо говоря так, mymodule.js:

запуск этого кода - после добавки в файл HTML:

Надо "покрыть" тестами (не слишком, но покрыть).
проблема в том, что я не нашел "архитектурно чистый" подход к тестированию приватных методов модуля.
с помощью nodeunit, я могу тестировать "public_method", создав каталог "test", и в нем файлик test_mymodule.js:

запуск теста просто:

Проблема в том, что доступа до mymodule.private_method() нету.
В данном примере, ессно, публичная метода - просто обертка и ни хрена не делает.
Но в реальном коде приватные методы - как раз то, что хотелось бы протестить.
И внешний API тоже, есссно. В общем идеи были разные.
Две наиболее популярные были:
1. "загрязнить" боевой модуль дополнительным тестовым кодом
Он потом отошлется клиенту непонятно к чему), приведея его к форме:

в тесте определить переменную:


2. разделить mymodule на внутренний под-модуль и тестить оный извне
т.е.:



И соотв. в тесте будет 2 региона тестирования:


в C++ можно было сделать какой-то изврат с #ifdef, и этот изврат не попал бы в релизный бинарник.
Как же быть в JS?


Это сообщение отредактировал(а) bilbobagginz - 5.4.2013, 15:05

Приватные методы не должны покрываться тестами. Если такое необходимость возникает, значит архитектурно приложение не правильно построено.

К тому же скоро готовится к релизу ECMAScript 6, где есть поддержка модулей. Там-то приватные методы вообще не получится протестировать. 

CruorVult, спасибо.
т.е. второй вариант (если много приватных метод вынести их в "утиль"ный модуль, использовать в главном, и тестить утильный модуль отдельно)

насчет "скоро".... 
гугл тут свой дротик (в смысле Dart) замутили... и сидят они как стандартные члены борда ECMA.
у тебя есть какая-то секретная инфа насчет когда это произойдет ?

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

Изначально ты все правильно сделал.

 

Осталось протестировать, когда метод ничего не принимает

 

Таким образом полностью покрылся приватный метод.

Лучше всего, при разработке с написанием тестов, использовать подход TDD. Эта техника по началу кажется непонятной и запутанной, но позволяет очень глубоко обдумать архитектуру приложения без строчки рабочего кода.

 



Точной информации нету, но предположительно к концу года.

т.е. к концу года браузеры волшебным образом запоют на новом жаргоне ?  (не верю)

Добавлено через 2 минуты и 34 секунды

знаком, но по физиологическим причинам страдаю излишним покрытием ненужного тестами, что нередко приводит к непокрытию нужноого 
не знаю как лечиться 

На фоне того, что Google переводит Chrome на новый движок рендеринга (Ripple) а также того, что Mozilla и Samsung разрабатывают новый движок для браузеров(под Android), переход на ECMAScript 6 меня ни капельки не удивляет