• <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 華夏之火 閱讀(1540) 評論(0)  編輯 收藏 引用 所屬分類: c++技術(shù)探討

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            av无码久久久久久不卡网站| 久久久91精品国产一区二区三区| 久久久久久国产精品无码下载| 7国产欧美日韩综合天堂中文久久久久 | 人妻无码精品久久亚瑟影视| 区久久AAA片69亚洲| 青青草原精品99久久精品66| 四虎国产精品免费久久5151| 久久综合伊人77777| 亚洲欧美久久久久9999| 久久99精品久久久久久hb无码| 亚洲综合精品香蕉久久网97| 一本色道久久88综合日韩精品 | 亚洲一级Av无码毛片久久精品| 久久男人Av资源网站无码软件| 2020最新久久久视精品爱 | 欧美一级久久久久久久大片| 久久亚洲日韩看片无码| 亚洲一区中文字幕久久| 伊人久久大香线蕉av不变影院| 99久久精品免费观看国产| 久久亚洲私人国产精品vA| 亚洲国产成人精品无码久久久久久综合| 久久免费的精品国产V∧| 国产69精品久久久久APP下载| 中文字幕久久欲求不满| 国产成人久久精品一区二区三区| 婷婷久久五月天| 久久免费视频一区| 久久综合久久伊人| 久久最新免费视频| 欧美亚洲另类久久综合婷婷| 久久精品成人免费国产片小草| 久久亚洲欧美日本精品| 久久久久久a亚洲欧洲aⅴ| 2022年国产精品久久久久| 久久亚洲精品人成综合网| 综合网日日天干夜夜久久 | 色综合久久综精品| 国产激情久久久久影院老熟女| 热99re久久国超精品首页|