java / scala에 좋지 않은 dbunit과 같은 프레임 워크가 있습니까?

java / scala에 좋지 않은 dbunit과 같은 프레임 워크가 있습니까?

---

저는 새롭고 가벼운 데이터베이스 채우기 프레임 워크를 만들 생각이었습니다. 나는 dbunit을 절대적으로 싫어한다. 그 전에 누군가 이미 그랬는지 알고 싶습니다.

내가 dbunit에 대해 싫어하는 것 :

1) 작성하고 시작하는 가장 간단한 형식은 더 이상 사용되지 않습니다. 그들은 부풀어 오른 형식을 사용하기를 원합니다. 일부는 xml 스키마가 필요합니다. 아 뭐 어쨌든.

2) 작성한 순서가 아닌 행을 채우지 만 순서대로 테이블이 xml 파일에 정의되어 있습니다. 외래 키 제약 조건이 문제를 일으키지 않는 방식으로 데이터를 정렬 할 수 없기 때문에 이것은 정말 나쁩니다. 이것은 당신이 그들을 완전히 끄는 번거 로움을 겪게 만듭니다.

이것은 또한 시간을 낭비하고 외래 키 제약 조건을 비활성화하는 코드를 포함하도록 junit 기본 클래스를 부풀립니다. 데이터베이스 유형 (hsqldb 등)을 테스트하고 데이터베이스 별 방식으로 비활성화해야 할 것입니다. 이것은 나쁘다.

dbunit이 프레임 워크의 일부로 외래 키 제약 조건을 자동으로 비활성화하는 데 도움이된다면 더 좋을 수 있지만 그렇게하지 않습니다. 그들은 방언을 추적합니다 ... 그래서 이것을 사용하지 않겠습니까? 궁극적으로이 모든 작업은 프로그래머가 시간을 낭비하고 빠르게 일어나서 테스트하지 않도록하는 것입니다.

3) XML은 작성하기가 어렵습니다. 나는 이것에 대해 더 말할 필요가 없습니다. 그들은 또한 그것을 할 수있는 많은 방법을 제공하므로 문제가 복잡하다고 생각합니다. 하나의 확실한 방법을 제공하고 완료하십시오.

4) 데이터가 커지면 ID와 일관성 / 올바른 관계를 추적하는 것이 큰 고통입니다.

또한 한 달 동안 프로젝트 작업을하지 않으면 user_id 1은 관리자, user_id 2는 비즈니스 사용자, user_id 3은 엔지니어, user_id 4는 다른 것임을 어떻게 기억하십니까? 이것을 확인하기 위해 돌아가는 것은 더 많은 시간을 낭비하고 있습니다. 임의의 숫자 이외의 의미있는 검색 방법이 있어야합니다.

5) 느립니다. 나는 hsqldb를 사용하지 않으면 고통스럽고 느리다는 것을 발견했습니다. 그럴 필요는 없습니다. "즉시"수행하기가 쉽지 않기 때문에 구성을 엉망으로 만드는 방법도 많습니다. 제대로 작동하려면 통과해야하는 혹이 있습니다. 이 모든 것은 사람들이 그것을 사용하지 않도록 장려하거나 그들이 그것을 사용하기 시작할 때 열 받게하는 것입니다.

6) 일부 값은 자주 반복되는 경향이 있으며 날짜를 좋아합니다. 기본값을 지정하거나 프레임 워크가 기본값을 넣도록 지시하지 않아도 자동으로 기본값을 넣도록하는 것이 좋습니다. 이렇게하면 원하는 값으로 만 개체를 ​​만들고 나머지는 그대로 둘 수 있습니다. 이것은 필요하지 않은 경우 열의 구석 구석을 지정하는 것보다 확실합니다.

7) 아마도 가장 성가신 것은 첫 번째 항목에 모든 값 (널 자리 표시 자 포함)이 포함되어야한다는 것입니다. 그렇지 않으면 미래의 행이 실제로 지정한 열을 선택하지 않을 것입니다.

DBunit에는 [NULL]을 실제 null 값으로 변환하는 데 적절한 기본값이 없습니다. 수동으로 추가해야합니다. 누가 dbunit으로이 일을하지 않았습니까? 모두가 있습니다. 이러면 안돼!

이것이 의미하는 바는 다형성 객체가있는 경우 첫 번째 행에있는 각 하위 클래스의 조인 테이블에 모든 외래 키를 선언해야한다는 것입니다. 모든 서브 클래스 패턴에 대해 테이블을 수행하는 경우에도 여전히 첫 번째 행의 모든 ​​필드를 지정해야합니다. 이것은 끔찍합니다.

나를 만족시킬만한 것이 있습니까? 아니면 훨씬 더 나은 데이터베이스 테스트 프레임 워크의 다음 프레임 워크 개발자가되어야합니까?

---

나는 DbUnit을에 실제 대안 잘 모르는 것 같아요 의해 언급 한 도구 중 어떤 것도 @Joe는 내 눈에 없습니다 :

• Incanto : DB 불가지론 아님
• SQLUnit : 데이터베이스 저장 프로 시저를 테스트하기위한 회귀 및 단위 테스트 하네스 (DbUnit의 의미가 아님)
• Cactus : In-container 테스트를위한 도구 (데이터베이스에서 도움이되는 부분을 보지 못함)
• Liquibase : 데이터베이스 마이그레이션 도구 (데이터를로드 / 확인하지 않음)
• ORMUnit : 데이터베이스를 초기화 할 수 있지만 그게 전부입니다.
• JMock : DbUnit과 전혀 경쟁하지 않습니다.

즉, 개인적으로 DbUnit을 크고 작은 프로젝트에서 여러 번 성공적으로 사용했으며 특히 Unitils 와 DbUnit 모듈을 사용할 때 꽤 유용 하다는 것을 알았습니다. 이것은 완벽하고 개선 할 수 없다는 것을 의미하지는 않지만 괜찮은 도구 (맞춤 제작 또는 Unitils와 같은 것)를 사용하면 괜찮은 경험이었습니다.

몇 가지 요점에 답하겠습니다.

1) 작성하고 시작하는 가장 간단한 형식은 더 이상 사용되지 않습니다. 그들은 부풀어 오른 형식을 사용하기를 원합니다. 일부는 xml 스키마가 필요합니다. 아 뭐 어쨌든.

DbUnit은 플랫 또는 구조화 된 XML, XLS, CSV를 지원합니다. 어떤 혁신적인 형식을 사용하고 싶습니까? 그런데 XML을 사용할 때 DTD 또는 스키마는 필수가 아닙니다. 하지만 유효성 검사 및 자동 완성과 같은 좋은 기능을 제공합니다. 그게 어떻게 나쁠까요? Unitils는이를 쉽게 생성 할 수 있습니다 . 데이터베이스 구조의 XSD 또는 DTD 생성을 참조 하십시오 .

dbunit이 프레임 워크의 일부로 외래 키 제약 조건을 자동으로 비활성화하는 데 도움이된다면 더 좋을 수 있지만 그렇게하지 않습니다. 그들은 방언을 추적합니다 ... 그래서 이것을 사용하지 않겠습니까? 궁극적으로이 모든 작업은 프로그래머가 시간을 낭비하고 빠르게 일어나서 테스트하지 않도록하는 것입니다.

그들은 당신의 패치를 기다리고 있습니다.

한편, Unitils는 제약 조건을 투명하게 처리하는 지원을 제공합니다 . 제약 조건 비활성화 및 시퀀스 업데이트를 참조하십시오 .

3) XML은 작성하기가 어렵습니다. 나는 이것에 대해 더 말할 필요가 없습니다. 그들은 또한 그것을 할 수있는 많은 방법을 제공하므로 문제가 복잡하다고 생각합니다. 하나의 확실한 방법을 제공하고 완료하십시오.

고통은 주관적이라고 생각하지만 특히 스키마와 자동 완성을 사용할 때 고통스럽지 않습니다. 당신이 제안하는 은색 총알은 무엇입니까?

4) 데이터가 커지면 ID와 일관성 / 올바른 관계를 추적하는 것이 큰 고통입니다.

그것들을 작게 유지하십시오 . 이것이 최고의 모범 사례 입니다. 알려진 모범 사례에 어긋나고 불평합니다 ...

또한 한 달 동안 프로젝트 작업을하지 않으면 user_id 1은 관리자, user_id 2는 비즈니스 사용자, user_id 3은 엔지니어, user_id 4는 다른 것임을 어떻게 기억하십니까? 이것을 확인하기 위해 돌아가는 것은 더 많은 시간을 낭비하고 있습니다. 임의의 숫자 이외의 의미있는 검색 방법이 있어야합니다.

예, 작업 전환은 비생산적입니다. 그러나 낮은 수준의 데이터로 작업하기 때문에 데이터가 어떻게 표현되는지 알아야합니다. 물론 높은 수준의 API를 사용하지 않는 한 마법의 해결책은 없습니다 (하지만 DbUnit의 목적은 아닙니다).

5) 느립니다. 나는 hsqldb를 사용하지 않으면 고통스럽고 느리다는 것을 발견했습니다. 그럴 필요는 없습니다. "즉시"수행하기가 쉽지 않기 때문에 구성을 엉망으로 만드는 방법도 많습니다. 제대로 작동하려면 통과해야하는 혹이 있습니다. 이 모든 것은 사람들이 그것을 사용하지 않도록 장려하거나 그들이 그것을 사용하기 시작할 때 열 받게하는 것입니다.

이는 DbUnit이 아니라 데이터베이스와 JDBC에 내재되어 있습니다. 가능한 한 빨리 작업을 수행하려면 H2와 같은 빠른 데이터베이스를 사용하십시오 (일을 수행하는 더 나은 불가지론적인 방법이 있다면 기꺼이 배울 것입니다).

6) 아마도 가장 성가신 것은 첫 번째 항목에 모든 값 (널 자리 표시 자 포함)이 포함되어야한다는 것입니다. 그렇지 않으면 향후 행이 실제로 지정한 열을 선택하지 않을 것입니다.

Unitils-Home-JavaPolis 2008 또는 Unit testing : unitils & dbmaintain 과 같은 프레젠테이션에서 언급 한대로 Unitils를 사용하는 경우에는 해당되지 않습니다 .

나를 만족시킬만한 것이 있습니까? 아니면 훨씬 더 나은 데이터베이스 테스트 프레임 워크의 다음 프레임 워크 개발자가되어야합니까?

더 나아질 수 있다고 생각한다면 기존 솔루션에 기여할 수 있습니다. 그것이 불가능하고 킬러 데이터베이스 테스팅 프레임 워크를 만들 수 있다고 생각한다면, 제가 말할 수있는 것은 그렇게하십시오. 그러나 잊지 마세요. 외침은 쉽기 때문에 자신의 솔루션을 사용하여 솔루션을 찾는 것은 그다지 적습니다.

---

DbUnit 개발자로서 비판에 감사 드리며 부분적으로 동의해야합니다. 우리는 현재 다음 DbUnit 주요 릴리스의 디자인을 시작하고 있으며 토론과 개발에 모두 참여하도록 초대합니다.

I'm not going to answer your points as your question is not really related to DbUnit, but to DbUnit alternatives. Anyway, I just want to highlight your point 7 is completely false: you do not need to specify all the columns on first row any more, the feature is called column sensing. I'm not going to tell you why it's not enabled by default as you are surely smart enough to understand it by yourself.

I'll give scaladbtest a deep examination in the hope we can integrate their ideas.

---

Faced with similar concerns using DBUnit I have found this : http://dbsetup.ninja-squad.com/index.html which may address concerns. Such as instead of representing test data in separate files all DB content is contained within the java class itself.

---

If you use the Spring Framework (or don’t mind using it at least for testing), then Spring DBUnit is currently the best (maintained) alternative to plain DBUnit that I know and use. Quoting their website:

Spring DBUnit provides integration between the Spring testing framework and the popular DBUnit project. It allows you to setup and teardown database tables using simple annotations as well as checking expected table contents once a test completes.

Spring DBUnit appears to be the ‘somewhat official’ Spring solution for DB unit testing (with DBUnit); at least the author/maintainer of the library, Phil Webb, is working at SpringSource/Pivotal.

---

I use DBUnit, with a few wrappers to smooth over the rough edges. A nice tool that can either complement or overlap the functionality is Jailer. It can extract subsets of data from a reference database, and store this as either DBUnit compatible XML files, or as "topologically sorted DML files", which respect the foreign key constraints.

---

You're making excellent point.

I've been working for a lot of web portals over the last years, mostly with PHP, but also some Java now and then.
And like you I don't get that after all these years framework and unittesting developers don't seem to realize how much storage handling has changed in the last decade. It's not enough to just send create/insert/truncate statements to some database! If you're operating at large scale you end up employing all sorts of storage backends, organized in layers to push hot content out fast. Plus on the Database front there's the issue of data partitioning. If you don't have a proper foreign key abstraction provided you will certainly go nuts when your storage setup changes. And while we're at it: fixture ordering by foreign key precedence has many pitfalls and I have yet to see a real solution for that with DBUnit.

Anyway, the point is having just a basic database storage in place for unittesting is not enough for complex storage setups, since they often fail to reproduce problems in the live environment and are a pain in the ass to maintain.

Without wanting to sound like a fanboy: one place where things are okay is ruby on rails. That has a persistent model concept that people seem to have actually put some thought into. If you're dealing in PHP, Symfony is the place to go. It is limited via the default inclusion of Doctrine, with is also quite DB-centric, but it has clean interfaces and great extensibility and copied the rails fixture system completely. Professionally I need to stick to homebrew solutions for now, but they work okay.

---

I just released a library called JDBDT (Java Database Delta Testing) that you may use for database setup and validation in software tests.

Have a look at http://jdbdt.org

Best, Eduardo

---

Here's a short list of a few tools in this vein (besides DBunit) that I particularly like, or find interesting. At the very least they may offer some inspiration:

• Incanto
• SQLunit
• Cactus
• Liquibase
• ORMUnit
• JMock

Note that none of these are really competitors to DBunit in terms of scope or feature sets. However, there are some interesting ideas there that might be worth taking a look at. Good luck!

---

We are writing Daleq as a wrapper around DbUnit to address some of the mentioned concerns. It allows populating a DB just within your unit test rather than relying on editing XML files.

---

I too had similar issues with DBUnit. Especially for using it to populate local development data and exporting data from a real database. I ran into several cases where it would export a dataset that it couldn't then import.

This inspired me to write a new library for it: https://github.com/jeffskj/phonydata

This uses a groovy DSL to define the datasets which makes for a very compact representation of the data and makes it possible to do cool things like generate random data since it's just groovy code.

---

The situation of DBUnit is indeed sometimes frustrating. Some of the problem are solved from Marc Philipp with dbunit-datasetbuilder, specially if you combine it with the validator, which is in a very early stage. You can see it in action at SZE.

Disclaimer: All referenced github-resources are maintained by me.

---

An alternative using Spring configuration and Specs2 testing can be found here

---

I just released a groovy DSL based framework called pedal-loader available via github. Documentation here.

It allows you to work with JPA entity level abstraction directly. Since it is a groovy script, you can use all of the groovy constructs.

ID, 이름 및 등급이라는 필드 (데이터베이스 열이 아니라 매핑 된 필드)가있는 Student라는 JPA 엔터티가 지원하는 테이블에 행을 삽입하려면 다음과 같이하십시오.

allStudents = table(Student, ['id', 'name', 'grade']) {
    row 1, 'Joe', Grade.A
    rowOfInterest = row 2, 'John', Grade.B
}

Grade는 데이터베이스 열에 매핑 된 Student 클래스의 열거 형입니다 (JPA 2.1 @Convert 주석 사용). allStudents는 행을 보유 할 목록이고 rowOfInterest는 특정 행에 대한 참조입니다. 이러한 속성 (allStudents 및 rowOfInterest)은 단위 테스트에서 사용할 수 있습니다.

참고 URL : https://stackoverflow.com/questions/3950002/is-there-a-dbunit-like-framework-that-doesnt-suck-for-java-scala