lưu trữ dữ liệu thử nghiệm đơn vị

Question

Giả sử tôi có giao diện với phương thức lưu trữData (khóa, dữ liệu) 'và' getData (khóa) '. Tôi nên thử nghiệm một cách thực hiện cụ thể như thế nào? Tôi có nên kiểm tra xem dữ liệu đã được đặt chính xác trong phương tiện lưu trữ (ví dụ: cơ sở dữ liệu sql) hay tôi chỉ nên kiểm tra xem liệu dữ liệu có chính xác không bằng cách sử dụng getData?

Nếu tôi tìm kiếm dữ liệu trong cơ sở dữ liệu, tôi cảm thấy như tôi cũng đang kiểm tra nội bộ của phương pháp nhưng chỉ kiểm tra xem liệu nó có mang lại dữ liệu giống nhau không.

Answer 1

Tôi nghĩ điều đó phụ thuộc vào những gì xảy ra với dữ liệu sau này - nếu bạn chỉ truy cập dữ liệu bằng cách sử dụng storeData và getData, tại sao không thử nghiệm các phương pháp trong buổi hòa nhạc? Tôi cho rằng đó là một cơ hội mà một lỗi sẽ phát sinh và nó sẽ có một chút khó khăn hơn để tìm ra cho dù đó là trong storeData hoặc getData, nhưng tôi muốn xem xét rằng một nguy cơ có thể chấp nhận nếu nó

1. làm cho thử nghiệm của bạn dễ dàng hơn để thực hiện và
2. che giấu các internals, như bạn nói

Nếu dữ liệu sẽ được đọc từ, hoặc chèn vào, cơ sở dữ liệu sử dụng một số cơ chế khác, sau đó tôi muốn kiểm tra các cơ sở dữ liệu sử dụng SQL như bạn đề nghị.

@brendan làm cho một điểm tốt, mặc dù - tùy theo phương pháp nào bạn quyết định, bạn sẽ chèn dữ liệu vào cơ sở dữ liệu. Bạn nên xóa dữ liệu trước và sau khi kiểm tra để đảm bảo rằng bạn có thể đạt được kết quả nhất quán.

Answer 2

Trong trường hợp như thế này, tôi thường sẽ tạo phương thức SetUp và TearDown để kích hoạt trước/sau khi kiểm tra đơn vị của tôi. Những phương pháp này sẽ thiết lập bất kỳ dữ liệu thử nghiệm nào tôi cần trong db và xóa bất kỳ dữ liệu thử nghiệm nào khi tôi hoàn thành. Ví dụ về mã giả:

Const KEY1 = "somekey" 
Const VALUE1= "somevalue" 


Const KEY2 = "somekey2" 
Const VALUE2= "somevalue2" 



Sub SetUpUnitTests() 
{ 
    Insert Into SQLTable(KEY1,VALUE1) 
} 


//this test is not dependent on the setData Method 
Sub GetDataTest() 
{ 
    Assert.IsEqual(getData(KEY1),VALUE1) 
} 

//this test is not dependent on getData Method 
Sub SetDataTest() 
{ 
    storeData(newKey,NewData) 
    Assert.IsNotNull(Direct Call to SQL [Select data from table where key=KEY2]) 

} 

Sub TearDownUnitTests() 
{ 
    Delete From table Where key in (KEY1, KEY2) 
} 

Answer 3

Bạn dường như bị cuốn vào thử nghiệm đơn vị, những gì bạn sẽ làm thực sự là thử nghiệm tích hợp. Việc thiết lập và lấy lại cùng một giá trị từ cùng một khóa là kiểm tra đơn vị bạn thực hiện với việc thực hiện giả của công cụ lưu trữ, nhưng thực sự kiểm tra bộ nhớ thực, nói cơ sở dữ liệu của bạn, như bạn nên, không còn là kiểm thử đơn vị nữa , nhưng nó là một phần cơ bản của thử nghiệm và có vẻ như thử nghiệm tích hợp với tôi. Không sử dụng thử nghiệm đơn vị làm búa của bạn, chọn đúng công cụ cho đúng công việc. Chia thử nghiệm của bạn thành nhiều lớp hơn.

Answer 4

Thử nghiệm cả trong buổi hòa nhạc là một kỹ thuật phổ biến (ít nhất, theo kinh nghiệm của tôi), và tôi sẽ không né tránh nó. Tôi đã sử dụng cùng một mẫu này để tuần tự hóa/deserializing và phân tích cú pháp và in ấn.

Nếu bạn không muốn nhấn cơ sở dữ liệu, bạn có thể sử dụng mô hình cơ sở dữ liệu. Một số người có cảm giác giống như bạn khi sử dụng mocks - nó là một phần thực hiện cụ thể. Như trong tất cả mọi thứ, đó là một sự cân bằng: xem xét các lợi ích của việc nhạo báng (nhanh hơn, không phụ thuộc vào db) so với nhược điểm của nó (sẽ không phát hiện các vấn đề db thực tế, chậm hơn).

Answer 5

Điều bạn muốn làm trong bài kiểm tra đơn vị là đảm bảo rằng phương thức thực hiện công việc mà nó phải làm. Nếu phương thức sử dụng các phụ thuộc để hoàn thành công việc của nó, bạn sẽ giả định các phụ thuộc đó và đảm bảo rằng phương thức của bạn gọi các phương thức trên các đối tượng mà nó phụ thuộc vào các đối số thích hợp. Bằng cách này bạn kiểm tra mã của bạn trong sự cô lập.

Một trong những lợi ích của việc này là nó sẽ thúc đẩy việc thiết kế mã của bạn theo một hướng tốt hơn. Ví dụ: để sử dụng chế độ nhạo báng, bạn tự nhiên bị hút về phía mã được tách riêng hơn bằng cách sử dụng tiêm phụ thuộc.Điều này cho bạn khả năng dễ dàng thay thế các đối tượng giả của bạn cho các đối tượng thực tế mà lớp của bạn phụ thuộc vào. Bạn cũng kết thúc việc triển khai các giao diện, được tạo ra một cách tự nhiên hơn. Cả hai thứ này đều là mẫu thiết kế tốt và sẽ cải thiện mã của bạn.

Để kiểm tra ví dụ cụ thể của bạn, bạn có thể có lớp của bạn phụ thuộc vào nhà máy để tạo kết nối tới cơ sở dữ liệu và người xây dựng để xây dựng các lệnh SQL được tham số được thực hiện thông qua kết nối. Bạn sẽ truyền các phiên bản này của các đối tượng này đến lớp của bạn và đảm bảo rằng các phương thức đúng để thiết lập kết nối và lệnh, xây dựng lệnh đúng, thực hiện nó và xé bỏ kết nối đã được gọi. Hoặc có lẽ, bạn tiêm một kết nối đã mở và chỉ đơn giản là xây dựng lệnh và gọi nó. Vấn đề là lớp của bạn được xây dựng dựa trên giao diện hoặc bộ giao diện và bạn sử dụng chế nhạo để cung cấp các đối tượng thực hiện các giao diện đó và có thể ghi lại các lời gọi và cung cấp các giá trị trả về đúng cho các phương thức mà bạn mong muốn sử dụng từ (các) giao diện.