How to avoid re-testing the same behavior with unit test in javascript? (methods visibility and unit test) -

tdd principle :

• test behavior of public method class. private method tested anyway cause public method called them. don't test private method.
• test expected behavior customer sergey berezovskiy explain here.

fair enough, seem , simple. however, in bellowing example, principle cause re-testing same thing more once. lead having second , third biggest mistake listed in top 5 tdd mistakes article. "too many setup" , "too many assertion".

example:

myclass = function () {     var self = this;         self.tasks = [];     self.isexpanded = false;     var _isloaded = false;       //private     function _loadtasks()     {         //api call load task         _sorttasks();     };      //private         function _sorttasks(tasks)     {         //sort self.tasks array     };      //public         self.method3 = function ()     {         //do stuff         if (hasdonesomething)         {             _sorttasks();         }     };      //public         self.method2 = function (param)     {         //do stuff         _sorttasks();     }      //public         self.method1 = function ()     {         if (self.isexpanded)             _collapse();         else             _expand();     };      //private         function _expand()     {         if (!_isloaded)         {             _loadtasks();         }         self.isexpanded = true;     };      //private         function _collapse()     {         self.isexpanded = false;     }; } 

in example above, 3 public methods may impact order of tasks. lead having assertion on sort order repeat in multiple test.

test("some test 2", 2, function () {     //setup      var myclass = builder.build();      //action     myclass.method2(someparam);      //assertion     ok( jobwasdoneproperly, "task should started");     ok( resuledsortisgood, "task started moved after started tasks , before unstarted ones"); });  test("some test 3", 3, function () {     //setup      var myclass = builder.build();      //action     myclass.method3();      //assertion     ok( taskloadedcorrectly, "tasks loaded");     ok( taskareexpanded, "tasks expanded");     ok( resuledsortisgood, "task started moved after started tasks , before unstarted ones"); }); 

having assertion on sort required setup verify resulted sort. causing mistake of having setup mentioned earlier.

issue solved by testing "private" method "sorttasks". way, assert "sorttask" called spy instead of testing resulted sort in test of "method1", "method2" , method3". doesn't reduce assertion count, reduce lot setup's length less verification required. however, indicate smell in code since go against tdd principle.

in c#, one way around create new class name "tasklist" inherit of list. implement public sort method it. use class hold "tasks" in "myclass" instead of array. way, wouldn't break rule "don't test private method" , nice. i'm in javascript , array knockout obserbalearrays, checked briefly if possible inherit of array in javascript. seemed possible i'm not interested in going there because didn't seem built in @ , complicated. don't want maintain such thing.

what proper way test sort in issue while respecting "don't test private method" rule?

first of in tdd test amount compared amount of code not sufficient. amount of code 200+ lines of tests.

you said correctly in c# inherit list, , inject via constructor. spy easily.

you should test outcome of whole sut , if sut doing , , sorts stuff implement , should not test sorting - or passing spy see happens.

also implement "private" function

myclass = function(){  _function privatefunc(){} } 

now cannot access outside

also if new js , suggest try out jasmine testing , goes c# developers