• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            huaxiazhihuo

             

            c++單元測試框架關(guān)鍵點記錄成員函數(shù)地址

            原則上,C++下最好的單元測試代碼應(yīng)該長成這樣子,用起來才是最方便的
            TEST_CLASS(className)
            {
                
            // 變量
                TEST_METHOD(fn1)
                {
                    
            // 
                }    
                TEST_METHOD(fn1)
                {
                    
            // 
                }
                
            //
            }
            vczh大神的測試代碼是這樣子,這是最方便使用的形式,但因為是以測試方法為粒度,大括號里面就是一個函數(shù)體,所以顯得功能上有些不足。
            TEST_CASE(ThisIsATestCase)
            {
            TEST_ASSERT(1+1==2);
            }
                  當(dāng)然,這里隱藏了很多宏的丑陋實現(xiàn),但是,那又有什么要緊呢。好不好并不是在于用了什么東西,goto,多繼承,宏,隱式類型轉(zhuǎn)換,……,這些,如果能夠顯著地減少重復(fù)性相似性代碼,還能帶來類型安全,然后又其潛在的問題又在可控的范圍之內(nèi),那么,又有什么理由拒絕呢。老朽一向認(rèn)為,語言提供的語法糖功能要多多益善,越多越好,當(dāng)然,必須像C++那樣,不用它們的時候,就不會帶來任何代價,那怕是一點點,就好像它們不存在,并且它們最好能正交互補。但是,你看看,cppunit,gtest的測試代碼又是什么貨色呢。
                  據(jù)說cppunit里面用了很多模式,其架構(gòu)什么的非常巧妙。反正使用起來這么麻煩,要做的重復(fù)事情太多了,這里寫測試函數(shù),那里注冊測試函數(shù),只能表示,慢走不送。gtest據(jù)說其架構(gòu)也大有講究,值得學(xué)習(xí),用起來,也比cppunit方便,但是,看看TEST_F,什么SetUp,TearDown,各種鬼麻煩,誰用誰知道。一句話,我們其實只需要class粒度的測試代碼,其他的一切問題就都是小case了。
                  當(dāng)然,class粒度的單元測試實現(xiàn)的難點在于收集要測試的成員函數(shù)。這里不能用虛函數(shù)。必須類似于mfc里面的消息映射成員函數(shù)表。也即是當(dāng)寫下TEST_METHOD(fn1),宏TEST_METHOD就要記錄下來fn1的函數(shù)指針。后面跟著的一對大括號體是fn1的函數(shù)體,已經(jīng)越出宏的控制范圍了,所以只能在前面大做文章。下面是解決這個問題的思路。這個問題在C++03之前的版本,比較棘手。但是,所幸,C++11帶來很多逆天的新功能,這個問題做起來就沒那么難了。下面的思路省略其他各種次要的細(xì)節(jié)問題。
            首先,我們定義一個空類和要測試的成員函數(shù)的形式。
            struct EmptyClass{};
            typedef void(EmptyClass::*TestMethodPtr)();
            還有存放成員函數(shù)地址的鏈表節(jié)點
            struct MethodNode
            {
                MethodNode(MethodNode
            *& head, TestMethodPtr method)
                {
                    mNext 
            = head;
                    head 
            = this;
                    mMethod 
            = method;
                }
                MethodNode
            * mNext;
                TestMethodPtr mMethod;
            };
            還有提取成員函數(shù)地址的函數(shù)

            template 
            <class OutputClass, class InputClass>
            union horrible_union{
                OutputClass 
            out;
                InputClass 
            in;
            };

            template 
            <class OutputClass, class InputClass>
            inline 
            void union_cast(OutputClass& outconst InputClass input){
                horrible_union
            <OutputClass, InputClass> u;
                static_assert(
            sizeof(InputClass) == sizeof(u) && sizeof(InputClass) == sizeof(OutputClass), "out and in should be the same size");
                u.
            in = input;
                
            out = u.out;
            }
            template
            <typename Ty>
            TestMethodPtr GetTestMethod(
            void(Ty::*testMethod)())
            {
                TestMethodPtr methodPtr;
                union_cast(methodPtr, testMethod);
                
            return methodPtr;
            }
            方法是每定義一個測試函數(shù),在其上面就先定義一個鏈表節(jié)點變量,其構(gòu)造函數(shù)記錄測試函數(shù)地址,并把自身加入到鏈表中。但是,在此之前,我們將遭遇到編譯器的抵觸。比如
            struct TestCase
            {
                typedef TestCase ThisType;
                MethodNode
            * mMethods = nullptr;

                TestMethodPtr mTestMethodfn1 
            = GetTestMethod(&fn1);
                void fn1(){}
            };
                  vc下面,編譯器報錯 error C2276: “&”: 綁定成員函數(shù)表達(dá)式上的非法操作
                  原來在就地初始化的時候,不能以這種方式獲取到地址。然后,試試在TestCase里面的其他函數(shù)中,包括靜態(tài)函數(shù),就可以將取地址符號用到成員函數(shù)前面。
                  這好像分明是編譯器在故意刁難,不過,任何代碼上的問題都可以通過引入中間層來予以解決。用內(nèi)部類。
            struct TestCase
            {
                typedef TestCase ThisType;
                MethodNode
            * mMethods = nullptr;

               
            struct Innerfn1 : public MethodNode
                {
                    Innerfn1(ThisType
            * pThis) : MethodNode(pThis->mMethods, GetTestMethod(&ThisType::fn1))
                    {
                    }
                } mTestMethodfn1 
            = this;
                
            void fn1(){}

                
            struct Innerfn2 : public MethodNode
                {
                    Innerfn2(ThisType
            * pThis) : MethodNode(pThis->mMethods, GetTestMethod(&ThisType::fn2))
                    {
                    }
                } mTestMethodfn2 
            = this;
                
            void fn2(){}
            };
                  有多少個測試方法,就動用多少種內(nèi)部類。然后,一旦定義一個測試類的變量,那么這些內(nèi)部類的構(gòu)造函數(shù)就執(zhí)行了,把測試方法串聯(lián)在一塊,逆序,也就是說最后定義測試方法反而跑到前面去了。這樣子就自動記錄下來所有的測試方法的地址。有了這些函數(shù)地址信息,后面怎么玩都可以。包括漂亮的測試結(jié)果顯示,日志記錄,甚至嵌入到vs的單元測試界面中,又或者是生成配置文件,各種花招,怎么方便就怎么玩。這個時候,可以拿來主義,把cppunit,gtest等的優(yōu)點都吸收過來。
                  是否覺得這還不夠,好像有很多事情要做。比如說,測試方法逆序了,在同一個測試類的變量上執(zhí)行這些測試方法,會不會就擾亂類的內(nèi)部信息了,每次new一個測試類,所有的測試方法都要重復(fù)記錄,內(nèi)部類變量要占內(nèi)存……。咳咳,這些都可以一一解決。這里只是用最簡明的方式展示自動記錄測試方法,產(chǎn)品級的寫法肯定大有講究了。
                  可以看到上面的代碼都是有意做成很相似的,這些都是準(zhǔn)備給宏大展身手的。這些低級宏太容易編寫了,任何經(jīng)歷mfc或者boost代碼折磨的猿猴,都完全能夠勝任,這就打住了。對了,這里的自動記錄成員函數(shù)的宏手法,可以大量地使用到其他地方,比如說,自動生成消息映射表,比mfc的那一套要好一百倍,應(yīng)用范圍太廣了。當(dāng)初老朽以為就只能用于單元測試框架的編寫上面,想不到其威力如此巨大,消息系統(tǒng)全靠它了。C++的每一項奇技淫巧和功能被發(fā)現(xiàn)后,其價值都難以估量,好像bs所說的,他老人家不會給c++增添一項特性,其應(yīng)用范圍一早就可以預(yù)料的。對付一個問題,C++有一百種解決方案,當(dāng)然里面只有幾種才最貼切問題領(lǐng)域,但是很多時候,我們往往只選擇或者尋找到另外的那90多種,最后注定要悲劇。

            posted on 2016-05-11 18:01 華夏之火 閱讀(1558) 評論(0)  編輯 收藏 引用 所屬分類: c++技術(shù)探討

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            久久久WWW成人免费毛片| 久久久久久毛片免费播放| 99久久亚洲综合精品成人| 亚洲精品高清国产一久久| 久久国产精品免费一区| 亚洲中文久久精品无码| 久久精品国产99国产电影网 | 国产精品熟女福利久久AV| 亚洲一区中文字幕久久| 亚洲欧美国产精品专区久久| 伊人久久大香线蕉综合Av| 国产精品女同一区二区久久| 久久久久久久精品妇女99| 国内精品久久久久影院免费| 伊人热热久久原色播放www| 99国产精品久久久久久久成人热| 狠狠色丁香婷婷综合久久来来去| 久久久久亚洲AV成人网人人网站| 久久av高潮av无码av喷吹| 狠狠狠色丁香婷婷综合久久五月| 一本综合久久国产二区| 亚洲一区中文字幕久久| 久久久久久人妻无码| 久久亚洲sm情趣捆绑调教| 伊人久久综在合线亚洲2019| 国产aⅴ激情无码久久| 久久久精品久久久久久 | 久久久艹| 伊人久久大香线蕉影院95| 久久精品国产亚洲av麻豆色欲| 精品久久久久久久久免费影院| 激情五月综合综合久久69| 国产精品久久久久久吹潮| 久久亚洲国产成人精品性色| 亚洲中文字幕久久精品无码APP| 性欧美大战久久久久久久| 欧美一级久久久久久久大片| 久久人搡人人玩人妻精品首页| 狠狠精品干练久久久无码中文字幕 | 国内精品久久久久影院一蜜桃| 久久久久亚洲AV无码专区首JN|