2013-09-30 12 views
6

ja testuje klasę utworzyć w Visual Studio 2012Jednostka operacja testowania CRUD w visual studio 2012

Moja Klasa kontroler jest:

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); 
    } 

I klasa test jest:

[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>(); 
    } 
} 

Utknąłem w sprawie testowej, pomóż mi.

Odpowiedz

5

pierwsze - stworzenie abstrakcji dla kodu dostępu do danych (szyderczy DbContext nie jest bardzo wygodna rzecz):

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

i zrobić kontroler zależy od niego

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

Pozwoli mock dane łatwo uzyskać dostęp do kodu. Dalej - napisać testy, które zweryfikować zachowanie kontrolera (Używam NUnit i Moq tutaj):

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); 
} 

I napisać realizacji:

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

    return View(member); 
} 
+1

To jest właśnie odpowiedź, że chciałem napisać – bAN

+0

Czy to też trzeba ' [TearDown] 'metoda oczyszczania? – christiandev

+0

@ christiandev tak nowe wartości przypisane do pól przed każdym uruchomieniem testu, nie potrzebujesz TearDown tutaj –

3

Co mam rozumieć testów jednostkowych jest: „tylko testu co metoda robi” Więc myślę, że trzeba przetestować metodę jest dobrze:

  • ModelState.IsValid

  • db.Members.Add (członek)

  • db.SaveChanges()

Ale nie dobre zachowanie ModelState lub DbContext. Są one testowane w ich własnych testach jednostkowych. Musisz potwierdzić, że połączenie zostało wykonane.

Aby wykonać ten rodzaj testu, należy użyć wzoru wstrzykiwania zależności Dependency i zastąpić rzeczywisty kontekst DbContext przez mocks. Te makiety tylko potwierdzają, że wywołanie jest dobrze wykonane bez udziału prawdziwego dbContext.

Nie jestem specjalistą od testowania jednostek, ale myślę, że musisz przemyśleć całą swoją architekturę, aby oddzielić swoje obiekty. Pozwala to na zamianę prawdziwych obiektów na mocks.