Làm thế nào để mô phỏng một DB để thử nghiệm (Java)?


76

Tôi đang lập trình bằng Java và các ứng dụng của tôi đang sử dụng rất nhiều DB. Do đó, điều quan trọng đối với tôi là có thể kiểm tra việc sử dụng DB của mình một cách dễ dàng.
Tất cả các bài kiểm tra DB là gì? Đối với tôi, họ nên cung cấp hai yêu cầu đơn giản:

  1. Xác minh cú pháp SQL.
  2. Quan trọng hơn, hãy kiểm tra xem dữ liệu có được chọn / cập nhật / chèn chính xác hay không, theo một tình huống nhất định.

Vậy thì, có vẻ như tất cả những gì tôi cần là một DB.
Nhưng thực ra, tôi không thích, vì có một số khó khăn khi sử dụng DB để kiểm tra:

  • "Chỉ cần kiếm cho mình một DB thử nghiệm, nó có thể khó đến mức nào?" - Chà, ở nơi tôi làm việc, để có một DB thử nghiệm cá nhân là điều khá bất khả thi. Bạn phải sử dụng DB "công khai", có thể truy cập được cho tất cả mọi người.
  • "Các bài kiểm tra này chắc chắn không nhanh ..." - Các bài kiểm tra DB có xu hướng chậm hơn các bài kiểm tra thông thường. Nó thực sự không lý tưởng để có các bài kiểm tra chậm.
  • "Chương trình này nên xử lý mọi trường hợp!" - Nó trở nên hơi khó chịu và thậm chí không thể thử và mô phỏng từng trường hợp trong DB. Đối với mỗi trường hợp, một số lượng truy vấn chèn / cập nhật nhất định sẽ được thực hiện, điều này gây khó chịu và mất thời gian.
  • "Chờ một chút, làm sao bạn biết có 542 hàng trong bảng đó?" - Một trong những nguyên tắc chính trong kiểm thử, là có thể kiểm tra chức năng theo một cách khác với mã được kiểm tra của bạn. Khi sử dụng DB, thường có một cách để thực hiện điều gì đó, do đó, bài kiểm tra hoàn toàn giống với mã lõi.

Vì vậy, bạn có thể nhận ra rằng tôi không thích DB khi nói đến các bài kiểm tra (tất nhiên tôi sẽ phải đạt được điều này trong một số thời điểm, nhưng tôi muốn đến đó sau khi kiểm tra, sau khi tôi tìm thấy hầu hết các lỗi khi sử dụng phần còn lại của các phương pháp thử nghiệm). Nhưng tôi đang tìm kiếm cái gì?

Tôi đang tìm cách để mô phỏng một DB, một DB giả, sử dụng hệ thống tệp hoặc chỉ bộ nhớ ảo. Tôi nghĩ rằng có thể có một công cụ / gói Java cho phép đơn giản tạo (sử dụng giao diện mã) một mô hình DB cho mỗi bài kiểm tra, với các bảng và hàng được mô phỏng, với xác minh SQL và với một giao diện mã để theo dõi trạng thái của nó (thay vì sử dụng SQL ).

Bạn có quen thuộc với loại công cụ này?


Chỉnh sửa: Cảm ơn vì câu trả lời! Mặc dù tôi đang yêu cầu một công cụ, bạn cũng đã cung cấp cho tôi một số mẹo liên quan đến vấn đề :) Tôi sẽ mất một chút thời gian để kiểm tra các đề nghị của bạn, vì vậy tôi không thể nói ngay bây giờ liệu câu trả lời của bạn có hài lòng không.

Dù sao, đây là một cái nhìn tốt hơn về những gì tôi đang tìm kiếm - Hãy tưởng tượng một lớp có tên DBMonitor, một trong những tính năng của nó là tìm số lượng hàng trong bảng. Đây là đoạn mã tưởng tượng về cách tôi muốn kiểm tra tính năng đó bằng JUnit:

public class TestDBMonitor extends TestCase {

    @Override
    public void setUp() throws Exception {

       MockConnection connection = new MockConnection();

       this.tableName = "table1";
       MockTable table = new MockTable(tableName);

       String columnName = "column1";
       ColumnType columnType = ColumnType.NUMBER;
       int columnSize = 50;
       MockColumn column = new MockColumn(columnName, columnType, columnSize);
       table.addColumn(column);

       for (int i = 0; i < 20; i++) {
           HashMap<MockColumn, Object> fields = new HashMap<MockColumn, Object>();
           fields.put(column, i);
           table.addRow(fields);
       }

       this.connection = connection;
    }

    @Test
    public void testGatherStatistics() throws Exception {

       DBMonitor monitor = new DBMonitor(connection);
       monitor.gatherStatistics();
       assertEquals(((MockConnection) connection).getNumberOfRows(tableName),
                    monitor.getNumberOfRows(tableName));
    }

    String tableName;
    Connection connection;
}

Tôi hy vọng mã này đủ rõ ràng để hiểu ý tưởng của tôi (xin lỗi vì lỗi cú pháp, tôi đã nhập thủ công mà không có Eclipse thân yêu của tôi: P).

Nhân tiện, tôi sử dụng ORM một phần và các truy vấn SQL thô của tôi khá đơn giản và không nên khác biệt giữa nền tảng này với nền tảng khác.

Câu trả lời:


24

câu trả lời mới cho câu hỏi cũ (nhưng mọi thứ đã tiến triển hơn một chút):

Làm thế nào để mô phỏng một DB để thử nghiệm (Java)?

bạn không mô phỏng nó. bạn mô phỏng kho lưu trữ của mình và bạn không kiểm tra chúng hoặc bạn sử dụng cùng một db trong các bài kiểm tra của mình và bạn kiểm tra sqls của mình. Tất cả các db trong bộ nhớ không hoàn toàn tương thích nên chúng sẽ không cung cấp cho bạn phạm vi bảo hiểm và độ tin cậy đầy đủ. và đừng bao giờ cố gắng mô phỏng / mô phỏng các đối tượng db sâu như kết nối, tập kết quả, v.v. nó không mang lại cho bạn giá trị nào và là một cơn ác mộng để phát triển và duy trì

để có một DB thử nghiệm cá nhân là khá bất khả thi. Bạn phải sử dụng DB "công khai", có thể truy cập được cho tất cả mọi người

Thật không may, rất nhiều công ty vẫn sử dụng mô hình đó nhưng bây giờ chúng tôi có docker và có hình ảnh cho hầu hết mọi db. các sản phẩm thương mại có một số hạn chế (như lên đến vài gb dữ liệu) không quan trọng đối với các thử nghiệm. bạn cũng cần lược đồ và cấu trúc của mình được tạo trên db cục bộ này

"Các bài kiểm tra này chắc chắn không nhanh ..." - Các bài kiểm tra DB có xu hướng chậm hơn các bài kiểm tra thông thường. Nó thực sự không lý tưởng để có các bài kiểm tra chậm.

vâng, các bài kiểm tra db chậm hơn nhưng chúng không chậm như vậy. Tôi đã thực hiện một số phép đo đơn giản và một bài kiểm tra điển hình mất 5-50ms. cái cần thời gian là khởi động ứng dụng. có rất nhiều cách để tăng tốc độ này:

  • khung DI đầu tiên (như mùa xuân) cung cấp một cách chỉ chạy một số phần ứng dụng của bạn. nếu bạn viết ứng dụng của mình với sự phân tách rõ ràng giữa logic liên quan db và không liên quan đến db, thì trong bài kiểm tra của bạn, bạn chỉ có thể bắt đầu phần db
  • mỗi db có nhiều tùy chọn điều chỉnh làm cho nó kém bền hơn và nhanh hơn nhiều. điều đó hoàn hảo để thử nghiệm. ví dụ về postgres
  • bạn cũng có thể đặt toàn bộ db vào tmpfs

  • một chiến lược hữu ích khác là có các nhóm kiểm tra và tắt các kiểm tra db theo mặc định (nếu chúng thực sự làm chậm quá trình xây dựng của bạn). theo cách này nếu ai đó thực sự đang làm việc trên db, anh ta cần chuyển cờ bổ sung trong dòng cmd hoặc sử dụng IDE (nhóm testng và bộ chọn kiểm tra tùy chỉnh là hoàn hảo cho việc này)

Đối với mỗi trường hợp, phải thực hiện một số lượng truy vấn chèn / cập nhật nhất định, điều này gây khó chịu và mất thời gian

phần 'mất thời gian' đã được thảo luận ở trên. có khó chịu không? Tôi đã thấy hai cách:

  • chuẩn bị một tập dữ liệu cho tất cả các trường hợp thử nghiệm của bạn. thì bạn phải duy trì nó và lý luận về nó. thường thì nó được tách khỏi mã. nó có kilobyte hoặc megabyte. nó rất lớn để xem trên một màn hình, để hiểu và lý luận. nó giới thiệu sự ghép nối giữa các bài kiểm tra. bởi vì khi bạn cần thêm hàng cho bài kiểm tra A, count(*)trong bài kiểm tra B của bạn không thành công. nó chỉ phát triển bởi vì ngay cả khi bạn xóa một số thử nghiệm, bạn cũng không biết hàng nào được sử dụng chỉ bởi một thử nghiệm này
  • mỗi bài kiểm tra chuẩn bị dữ liệu của nó. theo cách này, mỗi bài kiểm tra hoàn toàn độc lập, dễ đọc và dễ suy luận. có khó chịu không? imo, không hề! nó cho phép bạn viết các bài kiểm tra mới rất nhanh chóng và giúp bạn tiết kiệm rất nhiều công việc trong tương lai

làm thế nào để bạn biết có 542 hàng trong bảng đó? "- Một trong những nguyên tắc chính trong thử nghiệm, là có thể kiểm tra chức năng theo cách khác với mã đã thử nghiệm của bạn

uhm ... không hẳn. nguyên tắc chính là kiểm tra xem phần mềm của bạn có tạo ra đầu ra mong muốn để đáp ứng với đầu vào cụ thể hay không. vì vậy nếu bạn gọi dao.insert542 lần và sau đó dao.counttrả về 542, điều đó có nghĩa là phần mềm của bạn hoạt động như được chỉ định. nếu bạn muốn, bạn có thể gọi bộ đệm cam kết / thả ở giữa. Tất nhiên, đôi khi bạn muốn kiểm tra việc thực hiện của mình thay vì hợp đồng và sau đó bạn kiểm tra xem dao của bạn có thay đổi trạng thái của db hay không. nhưng bạn luôn kiểm tra sql A bằng cách sử dụng sql B (chèn so với select, trình tự next_val so với giá trị trả về, v.v.). vâng, bạn sẽ luôn gặp vấn đề 'ai sẽ kiểm tra các bài kiểm tra của tôi', và câu trả lời là: không ai cả, vì vậy hãy giữ chúng đơn giản!

các công cụ khác có thể giúp bạn:

  1. testcontainers sẽ giúp bạn cung cấp db thực.

  2. dbunit - sẽ giúp bạn làm sạch dữ liệu giữa các lần kiểm tra

    khuyết điểm:

    • rất nhiều công việc được yêu cầu để tạo và duy trì lược đồ và dữ liệu. đặc biệt là khi dự án của bạn đang trong giai đoạn phát triển chuyên sâu.
    • đó là một lớp trừu tượng khác, vì vậy nếu đột nhiên bạn muốn sử dụng một số tính năng db không được công cụ này hỗ trợ, có thể khó kiểm tra nó
  3. teste integration - mục đích cung cấp cho bạn vòng đời đầy đủ, sẵn sàng sử dụng và có thể mở rộng (tiết lộ: tôi là người sáng tạo).

    khuyết điểm:

    • chỉ miễn phí cho các dự án nhỏ
    • dự án rất trẻ
  4. đường bay hoặc liquibase - công cụ chuyển đổi db. chúng giúp bạn dễ dàng tạo lược đồ và tất cả các cấu trúc trên db cục bộ của bạn để kiểm tra.


6
Tôi phải đưa nó cho bạn, tôi không nghĩ rằng ai đó sẽ xem lại câu hỏi này và bận tâm viết một câu trả lời cập nhật. Tôi đã hỏi nó 8 năm trước, và kể từ đó tôi đã có được kinh nghiệm khiến tôi hầu như đồng ý với câu trả lời của bạn - đặc biệt là với phần về "chức năng thử nghiệm với cùng một mã".
Eyal Roth

40

Java đi kèm với Java DB .

Điều đó nói rằng, tôi sẽ khuyên bạn không nên sử dụng loại DB khác với loại DB bạn sử dụng trong sản xuất trừ khi bạn đi qua lớp ORM. Nếu không, SQL của bạn có thể không đa nền tảng như bạn nghĩ.

Ngoài ra, hãy xem DbUnit


10

Tôi đã sử dụng Hypersonic cho mục đích này. Về cơ bản, đó là một tệp JAR (một cơ sở dữ liệu Java trong bộ nhớ thuần túy) mà bạn có thể chạy trong JVM của chính nó hoặc trong JVM của riêng bạn và trong khi nó đang chạy, bạn có một cơ sở dữ liệu. Sau đó, bạn dừng nó và cơ sở dữ liệu của bạn biến mất. Tôi đã sử dụng nó - cho đến nay - như một cơ sở dữ liệu hoàn toàn trong bộ nhớ. Rất đơn giản để bắt đầu và dừng thông qua Ant khi chạy các bài kiểm tra đơn vị.


10

Có rất nhiều quan điểm về cách kiểm tra các điểm tích hợp chẳng hạn như kết nối Cơ sở dữ liệu qua SQL. Bộ quy tắc cá nhân của tôi đã hoạt động tốt cho tôi như sau:

1) Tách logic truy cập Cơ sở dữ liệu và các chức năng khỏi logic nghiệp vụ chung và ẩn nó sau một giao diện. Lý do: Để kiểm tra phần lớn logic trong hệ thống, cách tốt nhất là sử dụng giả / sơ khai thay cho cơ sở dữ liệu thực vì nó đơn giản hơn. Lý do 2: Nó nhanh hơn đáng kể

2) Coi các bài kiểm tra cho cơ sở dữ liệu là các bài kiểm tra tích hợp được tách biệt khỏi phần chính của bài kiểm tra đơn vị và cần chạy trên cơ sở dữ liệu thiết lập Lý do: Tốc độ và chất lượng của các bài kiểm tra

3) Mỗi ​​nhà phát triển sẽ cần cơ sở dữ liệu riêng biệt của họ. Họ sẽ cần một cách tự động để cập nhật cấu trúc của nó dựa trên những thay đổi từ đồng đội của họ và giới thiệu dữ liệu. Xem điểm 4 và 5.

4) Sử dụng một công cụ như http://www.liquibase.org để quản lý các nâng cấp trong cấu trúc cơ sở dữ liệu của bạn. Lý do: Cung cấp cho bạn sự nhanh nhẹn trong khả năng thay đổi cấu trúc hiện có và tiến lên trong các phiên bản

5) Sử dụng một công cụ như http://dbunit.sourceforge.net/ để quản lý dữ liệu. Thiết lập các tệp kịch bản (xml hoặc XLS) cho các trường hợp thử nghiệm cụ thể và dữ liệu cơ sở và chỉ xóa những gì cần thiết cho bất kỳ trường hợp thử nghiệm nào. Lý do: Tốt hơn nhiều so với việc chèn và xóa dữ liệu theo cách thủ công Lý do 2: Người kiểm tra dễ dàng hiểu cách điều chỉnh các tình huống hơn Lý do 3: Thực hiện điều này nhanh hơn

6) Bạn cần các bài kiểm tra chức năng cũng có DBUnit như dữ liệu kịch bản, nhưng đây là các tập dữ liệu lớn hơn nhiều và thực thi toàn bộ hệ thống. Điều này hoàn thành bước kết hợp kiến ​​thức rằng a) Các bài kiểm tra đơn vị chạy và do đó logic là hợp lý b) Việc kiểm tra tích hợp đối với cơ sở dữ liệu chạy và SQL là chính xác dẫn đến "và toàn bộ hệ thống hoạt động cùng nhau như một đầu để ngăn xếp dưới cùng "

Sự kết hợp này đã phục vụ tôi rất tốt cho đến nay để đạt được chất lượng cao của thử nghiệm và sản phẩm cũng như duy trì tốc độ phát triển thử nghiệm đơn vị và sự nhanh nhạy để thay đổi.


6

"Chỉ cần kiếm cho mình một DB thử nghiệm, nó có thể khó đến mức nào?" - Chà, ở nơi tôi làm việc, để có một DB thử nghiệm cá nhân là điều khá bất khả thi. Bạn phải sử dụng DB "công khai", có thể truy cập được cho tất cả mọi người.

Có vẻ như bạn đã gặp phải những vấn đề về văn hóa tại nơi làm việc đang là rào cản khiến bạn có thể hoàn thành công việc của mình với tất cả khả năng của mình và mang lại lợi ích cho sản phẩm của bạn. Bạn có thể muốn làm điều gì đó về điều đó.

Mặt khác, nếu lược đồ cơ sở dữ liệu của bạn đang được kiểm soát phiên bản thì bạn luôn có thể có một bản dựng thử nghiệm tạo cơ sở dữ liệu từ lược đồ, điền nó với dữ liệu thử nghiệm, chạy thử nghiệm của bạn, thu thập kết quả và sau đó loại bỏ cơ sở dữ liệu. Nó chỉ tồn tại trong khoảng thời gian của các bài kiểm tra. Nó có thể là một cơ sở dữ liệu mới trên cài đặt hiện có nếu phần cứng là vấn đề. Điều này tương tự như những gì chúng tôi làm ở nơi tôi làm việc.


6

Nếu bạn đang sử dụng Oracle tại nơi làm việc, bạn có thể sử dụng tính năng Điểm khôi phục trong Cơ sở dữ liệu Flashback để làm cho cơ sở dữ liệu quay trở lại thời điểm trước khi kiểm tra. Điều này sẽ xóa mọi thay đổi mà bạn đã thực hiện đối với DB.

Xem:

https://docs.oracle.com/cd/E11882_01/backup.112/e10642/flashdb.htm#BRADV71000

Nếu bạn cần một cơ sở dữ liệu thử nghiệm để sử dụng với sản xuất / công việc của Oracle thì hãy tra cứu cơ sở dữ liệu XE, phiên bản nhanh từ Oracle. Phần mềm này miễn phí cho mục đích sử dụng cá nhân, với giới hạn cơ sở dữ liệu có kích thước nhỏ hơn 2gb.


3

Gần đây chúng tôi đã chuyển sang JavaDB hoặc Derby để thực hiện điều này. Derby 10.5.1.1 hiện thực hiện biểu diễn trong bộ nhớ nên nó chạy rất nhanh, không cần phải vào đĩa: Derby In Memory Primer

Chúng tôi thiết kế ứng dụng của mình để chạy trên Oracle, PostgreSQL và Derby để chúng tôi không đi quá xa trên bất kỳ nền tảng nào trước khi phát hiện ra rằng một cơ sở dữ liệu hỗ trợ một tính năng mà các nền tảng khác không.


1

Tôi đồng ý với banjollity. Thiết lập môi trường phát triển và thử nghiệm biệt lập nên được ưu tiên cao. Mọi hệ thống cơ sở dữ liệu tôi đã sử dụng đều là mã nguồn mở hoặc có phiên bản dành cho nhà phát triển miễn phí mà bạn có thể cài đặt trên máy trạm cục bộ của mình. Điều này cho phép bạn phát triển dựa trên phương ngữ cơ sở dữ liệu tương tự như sản xuất, cung cấp cho bạn quyền truy cập quản trị viên đầy đủ vào cơ sở dữ liệu phát triển và nhanh hơn so với việc sử dụng máy chủ từ xa.


1

Cố gắng sử dụng trận derby . Nó rất dễ dàng và di động. Với Hibernate, ứng dụng của bạn trở nên linh hoạt. Thử nghiệm trong trận derby, sản xuất bất cứ thứ gì bạn thích và tin tưởng.


1

Chúng tôi đang tạo một môi trường kiểm tra cơ sở dữ liệu tại nơi làm việc ngay bây giờ. Chúng tôi cảm thấy chúng tôi phải sử dụng một hệ thống quản lý cơ sở dữ liệu thực với dữ liệu mô phỏng . Một vấn đề với DBMS mô phỏng là SQL không bao giờ thực sự hoàn toàn được coi là tiêu chuẩn, vì vậy một môi trường thử nghiệm nhân tạo sẽ phải hỗ trợ trung thực phương ngữ cơ sở dữ liệu sản xuất của chúng ta. Một vấn đề khác là chúng tôi sử dụng rộng rãi các ràng buộc giá trị cột, ràng buộc khóa ngoại và các ràng buộc duy nhất và vì một công cụ nhân tạo có thể sẽ không thực hiện những điều này, nên các bài kiểm tra đơn vị của chúng tôi có thể vượt qua nhưng các bài kiểm tra hệ thống của chúng tôi sẽ thất bại khi chúng lần đầu tiên thực những ràng buộc. Nếu quá trình kiểm tra mất quá nhiều thời gian, điều này cho thấy lỗi triển khai và chúng tôi sẽ điều chỉnh các truy vấn của mình (thông thường, các tập dữ liệu kiểm tra rất nhỏ so với quá trình sản xuất).

Chúng tôi đã cài đặt một DBMS thực trên mỗi máy nhà phát triển và trên máy chủ thử nghiệm và tích hợp liên tục của chúng tôi (chúng tôi sử dụng Hudson). Tôi không biết các giới hạn chính sách công việc của bạn là gì, nhưng cài đặt và sử dụng PostgreSQL, MySQL và Oracle XE khá dễ dàng. Tất cả đều miễn phí cho việc sử dụng phát triển (ngay cả Oracle XE), vì vậy không có lý do hợp lý nào để cấm sử dụng chúng.

Vấn đề quan trọng là làm thế nào để bạn đảm bảo rằng các bài kiểm tra của bạn luôn bắt đầu với cơ sở dữ liệu ở trạng thái nhất quán? Nếu tất cả các bài kiểm tra đều ở chế độ chỉ đọc, không có vấn đề gì. Nếu bạn có thể thiết kế các bài kiểm tra đột biến để luôn chạy trong các giao dịch không bao giờ cam kết, không có vấn đề gì. Nhưng thông thường, bạn cần phải lo lắng về việc đảo ngược các bản cập nhật. Để thực hiện việc này, bạn có thể xuất trạng thái ban đầu thành một tệp, sau đó nhập nó trở lại sau khi kiểm tra (các lệnh shell exp và imp của Oracle thực hiện điều này). Hoặc bạn có thể sử dụng một điểm kiểm tra / khôi phục. Nhưng một cách thanh lịch hơn là sử dụng một công cụ như dbunit , công cụ này hoạt động tốt cho chúng tôi.

Ưu điểm chính của việc này là chúng tôi phát hiện ra nhiều lỗi hơn ở phía trước, nơi chúng dễ sửa hơn rất nhiều và quá trình thử nghiệm hệ thống thực của chúng tôi không bị chặn trong khi các nhà phát triển cố gắng khắc phục sự cố. Điều này có nghĩa là chúng tôi tạo ra mã tốt hơn nhanh hơn và ít nỗ lực hơn.


1

Bạn có thể HSQLDB để kiểm tra db bộ nhớ. Khởi động cơ sở dữ liệu trong bộ nhớ và chạy thử nghiệm trên nó khá đơn giản.
http://hsqldb.org/


1

jOOQ là một công cụ ngoài việc cung cấp tính trừu tượng hóa SQL còn có các công cụ nhỏ được tích hợp sẵn như SPI cho phép giả mạo toàn bộ JDBC. Điều này có thể hoạt động theo hai cách như được ghi lại trong bài đăng blog này :

Bằng cách triển khai MockDataProviderSPI:

// context contains the SQL string and bind variables, etc.
MockDataProvider provider = context -> {

    // This defines the update counts, result sets, etc.
    // depending on the context above.
    return new MockResult[] { ... }
};

Trong cách triển khai trên, bạn có thể lập trình chặn mọi câu lệnh SQL và trả về kết quả cho nó, thậm chí tự động bằng cách "phân tích cú pháp" chuỗi SQL để trích xuất một số vị từ / thông tin bảng, v.v.

Bằng cách sử dụng đơn giản hơn (nhưng ít mạnh mẽ hơn) MockFileDatabase

... có định dạng như sau (một tập hợp các cặp câu lệnh / kết quả):

select first_name, last_name from actor;
> first_name last_name
> ---------- ---------
> GINA       DEGENERES
> WALTER     TORN     
> MARY       KEITEL   
@ rows: 3

Sau đó, tệp trên có thể được đọc và sử dụng như sau:

import static java.lang.System.out;
import java.sql.*;
import org.jooq.tools.jdbc.*;

public class Mocking {
    public static void main(String[] args) throws Exception {
        MockDataProvider db = new MockFileDatabase(
            Mocking.class.getResourceAsStream("/mocking.txt");

        try (Connection c = new MockConnection(db));
            Statement s = c.createStatement()) {

            out.println("Actors:");
            out.println("-------");
            try (ResultSet rs = s.executeQuery(
                "select first_name, last_name from actor")) {
                while (rs.next())
                    out.println(rs.getString(1) 
                        + " " + rs.getString(2));
            }
        }
    }
}

Lưu ý cách chúng tôi đang sử dụng API JDBC trực tiếp mà không thực sự kết nối với bất kỳ cơ sở dữ liệu nào.

Xin lưu ý, tôi làm việc cho nhà cung cấp của jOOQ nên câu trả lời này là thiên vị.

Hãy cẩn thận, tại một số điểm, bạn đang triển khai toàn bộ cơ sở dữ liệu

Những điều trên hoạt động cho các trường hợp đơn giản. Nhưng hãy cẩn thận rằng, cuối cùng, bạn sẽ triển khai toàn bộ cơ sở dữ liệu. Bạn muốn:

  1. Xác minh cú pháp SQL.

OK, bằng cách mô phỏng cơ sở dữ liệu như hình trên, bạn có thể "xác minh" cú pháp, bởi vì mỗi cú pháp mà bạn chưa biết trước trong phiên bản chính xác như đã liệt kê ở trên sẽ bị từ chối bởi bất kỳ cách tiếp cận chế nhạo nào như vậy.

Bạn có thể triển khai một trình phân tích cú pháp để phân tích cú pháp SQL ( hoặc, sử dụng lại jOOQ ), sau đó biến đổi câu lệnh SQL thành một thứ mà bạn có thể dễ dàng nhận ra hơn và tạo ra một kết quả. Nhưng cuối cùng, điều này chỉ có nghĩa là triển khai toàn bộ cơ sở dữ liệu.

  1. Quan trọng hơn, hãy kiểm tra xem dữ liệu có được chọn / cập nhật / chèn chính xác hay không, theo một tình huống nhất định.

Điều này làm cho mọi thứ thậm chí còn khó khăn hơn. Nếu bạn chạy một chèn và sau đó cập nhật, kết quả hiển nhiên khác với cập nhật trước rồi mới chèn, vì bản cập nhật có thể ảnh hưởng hoặc không ảnh hưởng đến hàng được chèn.

Làm thế nào để bạn đảm bảo điều này xảy ra khi "chế nhạo" một cơ sở dữ liệu? Bạn cần một máy trạng thái ghi nhớ trạng thái của từng bảng được "chế tạo". Nói cách khác, bạn sẽ triển khai một cơ sở dữ liệu.

Chế nhạo sẽ chỉ đưa bạn đến mức này

Như piotrek đã đề cập, chế nhạo sẽ chỉ đưa bạn đến mức này. Nó hữu ích trong những trường hợp đơn giản khi bạn chỉ cần chặn một vài truy vấn rất nổi tiếng. Điều đó là không thể, nếu bạn muốn giả lập cơ sở dữ liệu cho toàn bộ hệ thống. Trong trường hợp đó, hãy sử dụng cơ sở dữ liệu thực tế, lý tưởng là cùng một sản phẩm mà bạn đang sử dụng trong sản xuất.


1

Tôi nghĩ khung công tác Acolyte của tôi có thể được sử dụng cho mô hình DB như vậy: https://github.com/cchantep/acolyte .

Nó cho phép chạy Java hiện có (để thử nghiệm) với các kết nối mà bạn xử lý truy vấn / cập nhật: trả về tập kết quả thích hợp, số lượng cập nhật hoặc cảnh báo theo các trường hợp thực thi.


0

Để bắt đầu, bạn có đang sử dụng bất kỳ Lớp ORM nào để truy cập DB không?
Nếu không: thì những gì bạn đang nghĩ sẽ không có ích gì. Việc sử dụng thử nghiệm là gì khi bạn không chắc rằng SQL bạn đang kích hoạt sẽ hoạt động với DB của bạn trong sản xuất như trong các trường hợp thử nghiệm bạn đang sử dụng thứ khác.
Nếu có: Sau đó, bạn có thể xem xét các tùy chọn khác nhau được chỉ ra.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.