Пишем тестопригодный javascript

[@mckalech]

В ближайшее время планирую перевести еще несколько статей по тестированию js

[@filipovskii_off]

набор тестов не имеет доступа к приватным функциям, спрятанным в замыкания, а значит и не может их протестировать

я всегда думал, что приватное состояние как раз не нужно использовать в тестах. Иначе придётся переписывать тесты каждый раз когда мы меняем внутреннюю реализацию тестируемого объекта. Разве нет?

[@mckalech]

Если честно, подумал о том же во время перевода. Но это скорее замечание к автору.

[@vitalets]

Я думаю, истина где-то посередине.
Ведь может быть объект с одним публичным методом, который вызывает 10 приватных — для него будет тяжело писать тесты.

[@asci]

Ну так все зависит от того, при каких условиях он вызывает эти приватные методы. Надо покрыть все кейсы, и тогда все приватные методы будут протестированы

[@Untit1ed]

Вот не нравится стиль автора Зачем извращаться так с названием функции в примере с DataStore и возвращать объект с фунциями? Вроде хотел объяснить почему модульный паттерн — плохо для тестирования, а в итоге выдал тот же, но слегка переделанный модуль.
Не проще ли и более читательным будет следующий пример?

Пример

function DataStore(){
   this.data = [];
   this.push = function (item) {
      this.data.push(item);
   };
   this.pop = function() {
      return this.data.pop();        
   };
   this.length = function() {
      return this.data.length;
   }
}

var dataStore = new DataStore();

[@mckalech]

Думаю, пример показывает. как переписать уже существующий код с минимальными затратами. Хотя в целом, согласен, что не оч

[@dmlogv]

Думаю, что смысл в изоляции массива data. В его примерах он остается приватным, в вашем же — публичный.

[@rodweb]

Ну, вместо this.data делаем var data. Мне тоже стало непонятно, почему бы не использовать new для создания нового экземпляра.

[@dmlogv]

а если сделаем var data у нас разве не получится static-переменная, вместо поля нового экземпляра? (в терминологии не силен, но надеюсь, что понятно объяснил).

[@rodweb]

Переменная будет инициализироваться в контексте функции-конструктора каждый раз при создании экземпляра, поэтому нет. Пример.

[@rodweb]

Пример тут :-)

function Foo () {
  var bar = [];

  this.push = function (val) {
    bar.push(val);
  };

  this.get = function () {
    return bar;
  };
};

var a = new Foo();
var b = new Foo();
a.push(1);
a.push(2);
b.push(3);

a.get(); // [1, 2]
b.get(); // [3]

[@dmlogv]

Да, я уже потыкал консоль и убедился :-). Но в любом случае методы по-хорошему нужно убрать в прототайп, чтоб не захламлять память.

[@Untit1ed]

Если я не ошибаюсь, то прототипные методы привязаны к инстансам, а не к классам, таким образом через прототипные функции вы не получите доступа к приватным полям. Массиву data в нашем случае.

[@vba]

Насчет приватного состояния в тестах. В целом замечания о не-тестировании приватных методов верны, но не всегда. Автор(не переводчик) предлагает старый ободранный костыль. Своего рода я верю что зубные феи существуют и я верю что люди которые будут использовать мой код тоже верят в их существование, а следовательно «земля» _methodName магически защитит его от «публичного» использования.

Гораздо более гибким будет решение определить наш класс вот так:

//...
var 
  privateMethods = {
    // Private methods
  },
  finalObject = {
    // Public methods
  };

return env.isTest() ? underscore.extend(finalObject, privateMethods) : finalObject;

Да это остается костылем, но более гладким чем наивная вера в силу _methodName.

[@asci]

del

[@AndyGrom]

Избегайте создания приватных свойств с помощью замыканий

Подобные советы, автору поста не плохо бы оставить при себе и не мутить воду. Публичный интерфейс класса (объекта) должен быть самодостаточным для использования и не должен содержать ничего лишнего (всякие _foo и т.д.). Для чего нужно тестировать приватные части алгоритма ума не приложу. Что он хочет выяснить таким тестом? Что приватный код работает правильно? Это не даёт никакой гарантии, что публичный метод, который его использует, тоже будет работать правильно. Тестировать нужно только публичные методы. Только это даёт гарантию.
Вместо подобного совета, я бы лучше порекомендовал использовать тулу для анализа покрытия кода тестами. Пользы вагон, и, к тому же, при её использовании, многие вопросы по поводу внутренней жизни приватных функций отпадают сами сабой.