Cum bateți o clasă închisă?

Există o modalitate de a implementa o clasă sigilată de la o interfață ... și să machetezi interfața în schimb?

Ceva in mine simte ca, in primul rand, clasele sigilate sunt grele, dar asta e doar eu :)

Regula mea generală este că obiectele pe care trebuie să le bat joc ar trebui să aibă și o interfață comună. Cred că acest lucru este potrivit pentru design-înțelept și face testele mult mai ușor (și de obicei este ceea ce obțineți dacă faceți TDD). Mai multe despre acest lucru pot fi citite în Blogul de testare Google ultimul post (Vezi punctul 9).

De asemenea, am lucrat în principal în Java în ultimii 4 ani și pot spune că pot conta, pe de o parte, de câte ori am creat o clasă finală (sigilată). O altă regulă aici este că ar trebui să am întotdeauna un motiv bun pentru a sigila o clasă, spre deosebire de sigilarea ei în mod implicit.

Deși în prezent este disponibil numai în versiunea beta, cred că merită să ținem cont de shim caracteristica noului Fake framework (parte a versiunea Visual Studio 11 versiunea Beta).

Tipurile Shim oferă un mecanism pentru a ocoli orice metodă .NET unui delegat definit de utilizator. Tipurile de tip Shim sunt generate de codul generator al Fake-urilor și folosesc delegați, pe care îi numim tipuri de shim, pentru a specifica noile implementări ale metodei. Sub capotă, tipurile de șabloane utilizează callback-uri care au fost injectate la runtime în corpurile MSIL de metodă.

Personal, mă uitam la folosirea acestei metode pentru a bate metodele pe clase de clase închise, cum ar fi DrawingContext.

Cred că Moles , de la Microsoft Research, vă permite să faceți acest lucru. Din pagina Moles:

Moolele pot fi folosite pentru a ocoli orice .NET   inclusiv non-virtuale / statice   metode în tipuri sigilate.

UPDATE: there is a new framework called "Fakes" in the upcoming VS 11 release that is designed to replace Moles:

The Fakes Framework in Visual Studio 11 is the next generation of Moles & Stubs, and will eventually replace it. Fakes is different from Moles, however, so moving from Moles to Fakes will require some modifications to your code. A guide for this migration will be available at a later date.

Requirements: Visual Studio 11 Ultimate, .NET 4.5

Aproape întotdeauna evit dependențele de clasele externe adânc în codul meu. În schimb, aș prefera să folosesc un adaptor / pod pentru a vorbi cu ei. În acest fel, am de-a face cu semantica mea, iar durerea traducerii este izolată într-o singură clasă.

De asemenea, facilitează mișcarea dependențelor pe termen lung.

Problema cu TypeMock este că scuză designul rău. Acum, știu că este deseori un design rău al altcuiva pe care îl ascundeți, dar lăsându-l în procesul de dezvoltare poate duce foarte ușor la designul rău.

Cred că dacă folosești un cadru de batjocură, ar trebui să folosești un stil tradițional (ca Moq) și să creezi un strat de izolare în jurul lucrurilor care nu pot fi deplasate și să învingi stratul de izolare.

Pentru .NET, puteți utiliza ceva de genul TypeMock , care utilizează API-ul de profil și vă permite să vă conectați la apeluri aproape orice.

În general, iau calea de a crea o interfață și o clasă de adaptor / proxy pentru a facilita batjocurarea tipului sigilat. Cu toate acestea, am experimentat, de asemenea, să sărind crearea interfeței și efectuarea tipului de proxy non-sigilat cu metode virtuale. Acest lucru a funcționat bine atunci când proxy-ul este într-adevăr o clasă de bază naturală care încapsulează și utilizează o parte din clasa sigilată.

În cazul în care se ocupă de codul care a necesitat această adaptare, m-am săturat să realizez aceleași acțiuni pentru a crea interfața și tipul de proxy, astfel că am implementat o bibliotecă pentru a automatiza sarcina.

Codul este oarecum mai sofisticat decât eșantionul dat în articolul pe care îl referi, deoarece produce un ansamblu (în loc de cod sursă), permite generarea de coduri pentru orice tip și nu necesită o configurație mult mai mare.

For more information, please refer to this page.

Este perfect rezonabil să bateți o clasă sigilată deoarece multe clase cadru sunt sigilate.

În cazul meu, încerc să mă bat joc de clasa MessageQueue .Net, astfel încât să pot TDD logica meticuloasă de excepție.

Dacă cineva are idei despre cum să depășească eroarea lui Moq cu privire la "Configurarea nevalidă pe un membru care nu este supradimensionat", vă rog să-mi spuneți.

cod:

    [TestMethod]
    public void Test()
    {
        Queue messages = new Queue();
        Action sendDelegate = msg => messages.Enqueue(msg);
        Func receiveDelegate =
            (v1, v2) =>
            {
                throw new Exception("Test Exception to simulate a failed queue read.");
            };

        MessageQueue mockQueue = QueueMonitorHelper.MockQueue(sendDelegate, receiveDelegate).Object;
    }
    public static Mock MockQueue
                (Action sendDelegate, Func receiveDelegate)
    {
        Mock mockQueue = new Mock(MockBehavior.Strict);

        Expression> sendMock = (msmq) => msmq.Send(It.IsAny()); //message => messages.Enqueue(message);
        mockQueue.Setup(sendMock).Callback(sendDelegate);

        Expression> receiveMock = (msmq) => msmq.Receive(It.IsAny(), It.IsAny());
        mockQueue.Setup(receiveMock).Returns(receiveDelegate);

        return mockQueue;
    }

Am întâmpinat această problemă recent și după ce am citit / căutat pe web, pare că nu există o cale simplă în afară de a utiliza un alt instrument așa cum am menționat mai sus. Sau crud de manipulare lucruri ca mine:

• Creați instanță de clasă sigilată fără a fi apelat la constructor.

• System.Runtime.Serialization.FormatterServices.GetUninitializedObject (instanceType);

• Atribuiți valori proprietăților / câmpurilor prin reflecție

• YourObject.GetType() .GetProperty ("PropertyName") SetValue (dto, newValue, null);
• YourObject.GetType() GetField ("FieldName") SetValue (dto, newValue);