パブリックメソッド経由でテストする
多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。
テストできているか不安があるならテストカバレッジを確認しましょう。

別クラスのパブリックメソッドとする
プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを
示唆している場合があります。テストがどうしても書きたい場合は、その責務はテスト対象の
プライベートな振る舞いではなく、他の誰かのパブリックな振る舞いなのでしょう。テスト対象の
プライベートメソッドを「クラスの抽出」や「メソッド/関数の移動」を使って、テスト対象の
コラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。

テスト対象の可視性を（やや）上げる
例えば Java では、同一のパッケージからのみアクセスできる可視性があり（正式名称ではありませんが
「パッケージプライベート」と呼ばれます）、テストを同一パッケージに配置することでテストから
アクセスできるような設計を行うことがあります。（ただし、この質問の場合は JavaScript なので、この手段はとれません）

プライベートのまま、リフレクションでアクセスしてテストを書く
リフレクションは最後の手段であり、強力な手段でもあります。プロダクトコードに手を入れることが
できない状況や、レガシーコード（テストコードの無いコード）に対する「仕様化テスト（Characterization Test）」を
書いているような状況では、リフレクションは唯一の、かつ強力な手段になります。プライベートメソッドに
テストを書くことのデメリットを理解しつつ、黒魔術の強力さを堪能しましょう。
（ただし、この質問の場合は JavaScript なので、この手段はとれません。JavaScript は比較的緩い言語ですが、クロージャの情報隠蔽は非常に強固です）

まとめ
繰り返すと、プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^