1

質問のように、私のテストは可能な限り単純にする必要がありますか、それとも私がテストしている関数のロジックを模倣するロジックを含める必要がありますか？
例を挙げると、私はこの関数をテストしています。

$( 'ul.nav-tabs a' ).click( event_handlers.handle_set_tab_cookie );

var handle_set_tab_cookie = function( e ) {
    var active = $( this ).attr( 'href' );
    $.cookie( 'feeds_active_tab', active );
};

私のテストは、次のように単純に馬鹿げているはずです。

describe( "Facebook Feeds page", function() {
    beforeEach( function() {
        $( 'ul.nav' ).remove();
        var html = $('<ul class="nav nav-tabs"><li class="active"><a data-toggle="tab" href="#facebook">Facebook Feeds</a></li><li class=""><a data-toggle="tab" href="#ics">ICS</a></li></ul>');
        $('body').append( html );
    } )
    it( "Should call jQuery cookie to save the href ", function() {
        // Set up the listeners
        page.start();
        // Set up spies
        spyOn($, 'cookie');
        // Start the test
        var a = $( 'a[href=#facebook]' );
        a.trigger( 'click' );
        // verify that it has been called with the correct parameter
        expect($.cookie).toHaveBeenCalled();
        expect($.cookie).toHaveBeenCalledWith('feeds_active_tab', '#facebook'); 
    } );
    afterEach( function() {
        $( 'ul.nav' ).remove();
    } );
} );

または、すべてのテストを一度に実行できるように、反復/ロジックがありますか？

describe( "Facebook Feeds page", function() {
    beforeEach( function() {
        $( 'ul.nav' ).remove();
        var html = $('<ul class="nav nav-tabs"><li class="active"><a data-toggle="tab" href="#facebook">Facebook Feeds</a></li><li class=""><a data-toggle="tab" href="#ics">ICS</a></li></ul>');
        $('body').append( html );
    } )
    it( "Should call jQuery cookie to save the href ", function() {
        // Set up the listeners
        page.start();
        // Set up spies
        spyOn($, 'cookie');
        // Start the test and iterate over all the links
        $( 'ul.nav a' ).each( function(i, el) {;
                $(el).trigger( 'click' );
                // verify that it has been called with the correct parameter
                expect($.cookie).toHaveBeenCalled();
                expect($.cookie).toHaveBeenCalledWith('feeds_active_tab', $(el).attr('href'); 
                    } ); 
    } );
    afterEach( function() {
        $( 'ul.nav' ).remove();
    } );
} );
4

1 に答える 1

2

より複雑なテスト：

  1. 維持するのが難しい
  2. ドキュメントとして使用することはできません
  3. 読みにくく、ソフトウェアは書かれているよりも頻繁に読まれています
  4. 間違って書かれる可能性が高いです（誰が私たちのテストをテストしますか？）
  5. TDD中にAPIデザインを混乱させる可能性があります

一方、機能全体をカバーする単一のテストを作成してから、12個の小さなテストを作成する方が簡単で高速です。そのため、通常はこの方法が優先されます。要約すると、プロジェクトが長生きするように計画されている場合、私は可能な限り最小で最も単純なテストを作成します。それはより厳しいですが、将来的に利益を得るでしょう

于 2012-06-07T22:48:21.980 に答える