NUnit으로 데이터베이스 관련 코드를 어떻게 테스트합니까?

NUnit으로 데이터베이스 관련 코드를 어떻게 테스트합니까?

---

데이터베이스에 부딪히는 NUnit으로 단위 테스트를 작성하고 싶습니다. 각 테스트에 대해 데이터베이스를 일관된 상태로 유지하고 싶습니다. 트랜잭션을 통해 각 테스트를 "실행 취소"할 수 있다고 생각했기 때문에 주제에 대한 2004-05 년의 여러 기사를 검색했습니다.

• http://weblogs.asp.net/rosherove/archive/2004/07/12/180189.aspx
• http://weblogs.asp.net/rosherove/archive/2004/10/05/238201.aspx
• http://davidhayden.com/blog/dave/archive/2004/07/12/365.aspx
• http://haacked.com/archive/2005/12/28/11377.aspx

이는 각 테스트가 실행 된 후 DB 작업을 롤백하는 기능을 구축하는 NUnit에 대한 사용자 정의 속성을 구현하는 것으로 해결되는 것 같습니다.

훌륭하지만 ...

1. 이 기능은 기본적으로 NUnit 어딘가에 존재합니까?
2. 이 기술이 지난 4 년 동안 개선 되었습니까?
3. 이것이 데이터베이스 관련 코드를 테스트하는 가장 좋은 방법입니까?

---

편집 : DAL을 구체적으로 테스트하려는 것이 아니라 데이터베이스와 상호 작용하는 코드 조각을 테스트하려는 것입니다. 이러한 테스트를 "노터치"하고 반복 할 수 있으려면 각 테스트 후에 데이터베이스를 재설정 할 수 있으면 좋을 것입니다.

또한, 현재 테스트 장소가없는 기존 프로젝트에이를 쉽게 적용하고 싶습니다. 따라서 각 테스트에 대해 데이터베이스와 데이터를 처음부터 스크립팅 할 수 없습니다.

---

NUnit은 이제 [Rollback] 속성을 가지지 만 저는 다른 방식을 선호합니다. TransactionScope 클래스를 사용합니다 . 그것을 사용하는 몇 가지 방법이 있습니다.

[Test]
public void YourTest() 
{
    using (TransactionScope scope = new TransactionScope())
    {
        // your test code here
    }
}

TransactionScope에 커밋하도록 지시하지 않았으므로 자동으로 롤백됩니다. 어설 션이 실패하거나 다른 예외가 발생하더라도 작동합니다.

다른 방법은 [SetUp]을 사용하여 TransactionScope를 만들고 [TearDown]을 사용하여 Dispose를 호출하는 것입니다. 일부 코드 중복을 제거하지만 동일한 작업을 수행합니다.

[TestFixture]
public class YourFixture
{
    private TransactionScope scope;

    [SetUp]
    public void SetUp()
    {
        scope = new TransactionScope();
    }

    [TearDown]
    public void TearDown()
    {
        scope.Dispose();
    }


    [Test]
    public void YourTest() 
    {
        // your test code here
    }
}

NUnit이 TearDown이 호출되도록 보장하기 때문에 개별 테스트의 using 문만큼 안전합니다.

데이터베이스를 공격하는 테스트는 실제로 단위 테스트가 아니라고 생각합니다. 아직 작성하고 있지만 통합 테스트라고 생각합니다. 나는 여전히 그것들이 가치를 제공한다고 생각합니다. 자주 사용하는 한 곳은 LINQ to SQL 코드를 테스트하는 것입니다. 나는 디자이너를 사용하지 않습니다. DTO와 속성을 직접 작성합니다. 나는 그것을 잘못 이해하는 것으로 알려져 있습니다. 통합 테스트는 내 실수를 포착하는 데 도움이됩니다.

---

I just went to a .NET user group and the presenter said he used SQLlite in test setup and teardown and used the in memory option. He had to fudge the connection a little and explicit destroy the connection, but it would give a clean DB every time.

http://houseofbilz.com/archive/2008/11/14/update-for-the-activerecord-quotmockquot-framework.aspx

---

I would call these integration tests, but no matter. What I have done for such tests is have my setup methods in the test class clear all the tables of interest before each test. I generally hand write the SQL to do this so that I'm not using the classes under test.

Generally, I rely on an ORM for my datalayer and thus I don't write unit tests for much there. I don't feel a need to unit test code that I don't write. For code that I add in the layer, I generally use dependency injection to abstract out the actual connection to the database so that when I test my code, it doesn't touch the actual database. Do this in conjunction with a mocking framework for best results.

---

For this sort of testing, I experimented with NDbUnit (working in concert with NUnit). If memory serves, it was a port of DbUnit from the Java platform. It had a lot of slick commands for just the sort of thing you're trying to do. The project appears to have moved here:

http://code.google.com/p/ndbunit/

(it used to be at http://ndbunit.org).

The source appears to be available via this link: http://ndbunit.googlecode.com/svn/trunk/

---

Consider creating a database script so that you can run it automatically from NUnit as well as manually for other types of testing. For example, if using Oracle then kick off SqlPlus from within NUnit and run the scripts. These scripts are usually faster to write and easier to read. Also, very importantly, running SQL from Toad or equivalent is more illuminating than running SQL from code or going through an ORM from code. Generally I'll create both a setup and teardown script and put them in setup and teardown methods.

Whether you should be going through the DB at all from unit tests is another discussion. I believe it often does make sense to do so. For many apps the database is the absolute center of action, the logic is highly set based, and all the other technologies and languages and techniques are passing ghosts. And with the rise of functional languages we are starting to realize that SQL, like JavaScript, is actually a great language that was right there under our noses all these years.

Just as an aside, Linq to SQL (which I like in concept though have never used) almost seems to me like a way to do raw SQL from within code without admitting what we are doing. Some people like SQL and know they like it, others like it and don't know they like it. :)

참고URL : https://stackoverflow.com/questions/321180/how-do-i-test-database-related-code-with-nunit