Cơ sở dữ liệu phi giao dịch và kiểm tra tích hợp

Một vấn đề tôi nghĩ rằng tôi sẽ gặp phải với thử nghiệm tích hợp của mình là có nhiều thử nghiệm truy cập vào cùng một cơ sở dữ liệu. Mặc dù hiện tại đây không phải là vấn đề, tôi biết chúng tôi có nhiều ứng dụng ở đây truy cập cùng một cơ sở dữ liệu và tôi chỉ đang cố gắng nghĩ cách để ngăn chặn vấn đề này trước khi nó xảy ra.

Một ý tưởng tôi đã thấy rất nhiều là sử dụng các giao dịch. Khi bắt đầu, bạn bắt đầu một giao dịch và sau đó, bạn sẽ quay lại giao dịch. Điều này có nghĩa là nhiều thử nghiệm truy cập vào cùng một bảng cơ sở dữ liệu và sẽ không ảnh hưởng lẫn nhau. Vấn đề tôi gặp phải là trong trường hợp của tôi, 85-95% số bảng tôi đang làm việc với MySQL là MyISAM không hỗ trợ giao dịch.

Có cách nào để di chuyển xung quanh các công cụ lưu trữ không hỗ trợ giao dịch nhưng vẫn cho phép nhiều thử nghiệm truy cập vào cùng một bảng mà không ảnh hưởng đến nhau không? Từ những gì tôi nghe được, khung thử nghiệm ruby ​​trên đường ray sử dụng các giao dịch theo cách này, làm thế nào để họ khắc phục vấn đề này (hoặc họ)?

Trong công ty của tôi, đã có cuộc tranh luận đó: sự kiên trì là một vấn đề lớn để thử nghiệm.

Có một số hack sẽ giúp bạn có được một nửa. Chúng tôi quyết định không mất thời gian với họ:

• sử dụng Giao dịch mà bạn rollback . Điều đó thất bại như:
  • Đôi khi bạn mở một giao dịch bị cô lập (bên trong một giao dịch tổng quát hơn), vì vậy nó đã bị đóng trước khi mã kiểm tra của bạn có thể nắm bắt được nó
  • Bạn không thể kiểm tra sự kiên trì thực sự của bạn. (Điều gì xảy ra khi kiểm tra đóng một giao dịch và chạy truy vấn phức tạp bị ảnh hưởng bởi dữ liệu đó trong một giao dịch khác; hoặc lưu dữ liệu và tải lại sau đó.)
  • Bạn không thể kiểm tra mã của mình đầy đủ (chỉ các lớp dưới mức giao dịch; không đủ tốt nếu bạn xem xét các nhược điểm của kiểm tra tích hợp).
• sử dụng một cơ sở dữ liệu sạch mới cho mỗi bài kiểm tra . Điều đó cũng thất bại như:
  • bộ thử nghiệm của chúng tôi sẽ sớm đạt được một vài nghìn thử nghiệm (chúng tôi có các đội lớn). Thiết lập Cơ sở dữ liệu mới đòi hỏi tối thiểu vài phút (vì chúng tôi có nhiều danh mục và tham số là một phần của mỗi phiên bản). Bộ thử nghiệm của chúng tôi sẽ sớm mất vài tháng để hoàn thành và chúng tôi chỉ có thể chờ vài ngày.
  • chúng tôi sẽ cần một phiên bản cơ sở dữ liệu cụ thể cho từng nhà phát triển hoặc từng máy và có chính sách chỉ khởi chạy một thử nghiệm tại một thời điểm. Chúng ta cần sử dụng Oracle 11 để kiểm tra các truy vấn của mình có ổn không, điều đó sẽ quá tốn kém (giấy phép Oracle).
• làm sạch cẩn thận sau mỗi lần kiểm tra (khung kiểm tra cung cấp các móc để chạy mã sau khi kiểm tra). Điều đó thất bại như:
  • sẽ rất tốn kém để duy trì một kết hợp hoàn hảo giữa mã đó doesvà thử nghiệm đó undoes. Ngay sau khi trận đấu không hoàn hảo, các triệu chứng không rõ ràng, một bài kiểm tra có thể thất bại trong khi vài trăm dòng sau đó; hoặc một bài kiểm tra nên thất bại có thể vượt qua sai.
  • luôn luôn có các trường hợp cạnh mà việc làm sạch không đúng (sự cố máy hoặc phần mềm?). Điều đó để lại một trạng thái không xác định cho các vụ hành quyết sau này.
  • khi thử nghiệm hiển thị lỗi, trạng thái cơ sở dữ liệu sẽ là thông tin cần thiết, nhưng nó sẽ bị mất (vì chúng tôi dọn sạch trước khi thử nghiệm tiếp theo, để hoàn thành bộ thử nghiệm và hiển thị đầy đủ thông tin cho nhà phát triển).

Vì vậy, chúng tôi đã chuyển sang một chính sách mà chúng tôi biết là hợp lệ:

• có các bài kiểm tra đơn vị tự động cho các yêu cầu của chúng tôi :
  • nếu cần, giả lập cơ sở dữ liệu truy cập (nhưng chúng tôi thường không cần JMock, tôi có thể giải thích thiết kế của chúng tôi nếu được yêu cầu).
  • kiểm tra thực hiện với tốc độ trên 100 mỗi giây
  • kiểm tra nhanh chóng để viết, ngắn và rõ ràng để đọc.
  • các xét nghiệm không phụ thuộc vào bất kỳ trạng thái bền bỉ nào, vì vậy chúng được cách ly hoàn toàn với nhau một cách tự nhiên (không cần đến mecanism phức tạp)
• kiểm tra tích hợp với cơ sở dữ liệu riêng biệt (nghĩa là yêu cầu theo yêu cầu, không được tích hợp với logic ứng dụng).
  • chúng tôi đã xem xét tự động hóa nhiệm vụ đó, nhưng có vẻ như quá tốn kém (xem phần trước của bài viết của tôi)
  • vì vậy chúng tôi đã giữ các hướng dẫn kiểm tra này: mỗi nhà phát triển sửa đổi một truy vấn dự kiến ​​sẽ kiểm tra lại cơ sở dữ liệu (thường là một phần của các thử nghiệm đầu cuối của anh ấy thông qua giao diện người dùng).

Ngay cả khi bạn không có "giao dịch", theo nghĩa T-SQL, bạn vẫn nên cố gắng thực hiện các giao dịch của mình (theo nghĩa chung của thuật ngữ). Các xét nghiệm không nên dựa vào nhau và chúng có thể đảo ngược. Nếu bạn không có bất kỳ rollback chính thức hoặc phạm vi giao dịch, thì bạn có thể muốn thực hiện của riêng bạn. Ví dụ: bạn có thể yêu cầu các bài kiểm tra đơn vị của mình thực hiện việc dọn dẹp, trong đó chúng xóa tất cả các bản ghi được tạo trong bài kiểm tra.

Chỉ cần mỗi người dùng hoặc mỗi lần chạy ghi đè cơ sở dữ liệu được sử dụng. Đó là những gì chúng ta làm trong công việc. Sau đó, bạn không bao giờ có vấn đề với 2 bài kiểm tra đồng thời can thiệp lẫn nhau.

Chúng tôi có mỗi lần chạy thử xây dựng db lên với các lần di chuyển, điền vào db với các đồ đạc và sau đó xé chúng xuống sau đó kết thúc.

Nếu DBMS hỗ trợ các giao dịch, chúng tôi sẽ sử dụng nó làm tối ưu hóa cho thiết lập ban đầu và phân tích. Chúng là tùy chọn, mặc dù bài kiểm tra của bạn có thể chạy hơi lâu mà không có nó. Như mọi khi YYMV.

Không ồn ào, không ầm ĩ.