2013-09-30 20 views
6

sto testando la classe creare in Visual Studio 2012Unità operazione test CRUD in Visual Studio 2012

mia classe controller è:

public ActionResult Create() 
    { 
     return View(); 
    } 

    // 
    // POST: /Member/Create 

    [HttpPost] 
    public ActionResult Create(Member member) 
    { 
     if (ModelState.IsValid) 
     { 
      db.Members.Add(member); 
      db.SaveChanges(); 
      return RedirectToAction("Index"); 
     } 

     return View(member); 
    } 

E classe di test è:

[TestClass] 
public class MemberTest 
{ 

    [TestMethod] 
    public void Create(Member mem) 
    { 
     mem.MemID = 123; 
     mem.MemName = "sruthy"; 


     /// dont know what is writing. 

    } 
} 

SampleDataContext .cs

public class SampleDataContext:DbContext 
{ 
    public DbSet<Member> Members { get; set; } 
    protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     modelBuilder.Conventions.Remove<PluralizingTableNameConvention>(); 
    } 
} 

Sono bloccato nel test case, per favore aiutatemi.

risposta

5

In primo luogo - creare un'astrazione per il vostro codice di accesso ai dati (beffardo DbContext non è cosa molto comoda):

public interface IMemberRepository 
{ 
    void Add(Member member); 
} 

e rendere il controller dipendono da esso

public MemberController(IMemberRepository repository) 
{ 
    this.repository = repository; 
} 

Ciò consentirà dati finto codice di accesso facilmente. Avanti - scrivere i test che verificano il comportamento del controller (io uso NUnit e Moq qui):

private MemberController controller; 
private Mock<IMemberRepository> repositoryMock; 
private Member member; 

[SetUp] 
public void Setup() 
{ 
    repositoryMock = new Mock<IMemberRepository>(); 
    controller = new MemberController(repositoryMock.Object); 
    member = new Member { MemID = 123, MemName = "sruthy" }; 
} 

[Test] 
public void ShouldCreateMemberWhenItIsValid() 
{ 
    var result = (RedirectToRouteResult)controller.Create(member); 
    Assert.That(result.RouteValues["action"], Is.EqualTo("Index")); 
    repositoryMock.Verify(r => r.Add(member)); 
} 

[Test] 
public void ShouldNotCreateMemberWhenItIsNotValid() 
{ 
    controller.ModelState.AddModelError("MemName", "Something wrong"); 
    var result = (ViewResult)controller.Create(member); 
    Assert.That(result.ViewName, Is.Empty); 
} 

E scrivere implementazione:

[HttpPost] 
public ActionResult Create(Member member) 
{ 
    if (ModelState.IsValid) 
    { 
     repository.Add(member); 
     return RedirectToAction("Index"); 
    } 

    return View(member); 
} 
+1

Questa è esattamente la risposta che ho voluto scrivere – bAN

+0

Questo anche bisogno di ' [TearDown] 'metodo per la pulizia? – christiandev

+0

@christiandev quindi nuovi valori assegnati ai campi prima di ogni prova, non è necessario TearDown qui –

3

Quello che ho capito in unit testing è: "solo prova ciò che il vostro metodo sta facendo" Quindi penso che si deve mettere alla prova il metodo sta facendo bene:

  • ModelState.IsValid

  • db.Members.Add (utente)

  • db.SaveChanges()

Ma non il buon comportamento di ModelState o DbContext. Questi sono testati nei loro test di unità. Devi affermare solo che la chiamata è stata fatta.

Per eseguire questo tipo di test, è necessario utilizzare il modello di iniezione delle dipendenze e sostituire il vero DbContext con i mock. Questi mock stanno solo affermando che la chiamata è ben eseguita senza coinvolgere il vero dbContext.

Non sono uno specialista dei test unitari, ma penso che devi pensare a tutta la tua architettura per disaccoppiare i tuoi oggetti. Questo ti permette di sostituire oggetti reali con mock.

Problemi correlati