2015-03-21 26 views
9

Tôi muốn đảm bảo rằng trong trường hợp mã đang chạy trong chế độ thử nghiệm, nó không (vô tình) truy cập cơ sở dữ liệu sai. Cách tốt nhất để phát hiện nếu mã hiện đang chạy trong chế độ thử nghiệm là gì?Làm cách nào để phát hiện xem thử nghiệm mocha có đang chạy trong node.js không?

+0

Cách tốt nhất để tránh điều đó là giả lập lớp dữ liệu thực sự –

+0

Bạn đang chạy thử nghiệm ở đâu để có quyền truy cập vào tài nguyên sản xuất? Điều này cần được giải quyết ở cấp độ mạng. Cơ sở dữ liệu sản xuất chỉ nên chấp nhận các kết nối từ các máy sản xuất. –

+0

... nó có thể không phải là môi trường sản xuất. Tôi muốn đảm bảo rằng các thử nghiệm chạy với môi trường thử nghiệm. Nếu không, tôi sẽ ném một lỗi. –

Trả lời

12

Như đã đề cập trong nhận xét, thực tiễn không tốt là xây dựng mã của bạn nhận thức được các thử nghiệm. Tôi thậm chí không thể tìm thấy chủ đề được đề cập trên SO và thậm chí bên ngoài. Tuy nhiên, tôi có thể nghĩ ra cách để phát hiện sự kiện được đưa ra trong thử nghiệm. Đối với tôi, mocha không tự thêm vào phạm vi global, nhưng thêm global.it. Vì vậy, kiểm tra của bạn có thể

var isInTest = typeof global.it === 'function'; 

tôi sẽ đề nghị để chắc chắn bạn không giả phát hiện thêm séc global.sinonglobal.chai mà bạn có thể sử dụng hầu hết trong các thử nghiệm Node.js của bạn.

+0

Bây giờ là về xây dựng mã đang được nhận thức của các bài kiểm tra. Tôi muốn ném một lỗi nếu ai đó viết một bài kiểm tra chạy với các cài đặt triển khai. Ý tưởng là để bảo vệ một số chức năng "nguy hiểm" khỏi bị tình cờ gọi là mẫu thử nghiệm được định cấu hình sai (như thả bảng trên hệ thống sản xuất). –

+0

Một hành vi lạm dụng khác ... Môi trường của nhà phát triển không phải giải quyết cấu hình sản xuất trừ khi thực hiện khắc phục sự cố. Cấu hình của nhà phát triển chỉ có thể đạt được môi trường địa phương hoặc ít nhất là giai đoạn, nhưng không thể sản xuất. Tuy nhiên, đó là tất cả các ý kiến ​​và tư vấn, câu trả lời được cung cấp. Đừng quên để cho cộng đồng biết liệu nó có phù hợp với nhu cầu của bạn hay là sai –

+0

Đó là những trường hợp 'khắc phục sự cố', các nhà phát triển có xu hướng quên rằng họ được kết nối với cơ sở dữ liệu thực và chạy thử nghiệm có khả năng phá hủy dữ liệu ... –

3

Kiểm tra process.argv là một cách tiếp cận tốt trong kinh nghiệm của tôi.

Ví dụ nếu tôi console.log(process.argv) trong một thử nghiệm tôi nhận được như sau:

[ 
    'node', 
    '/usr/local/bin/gulp', 
    'test', 
    '--file', 
    'getSSAI.test.unit.js', 
    '--bail', 
    '--watch' 
] 

Từ đó bạn có thể thấy ngụm đang được sử dụng. Sử dụng yargs làm cho việc diễn dịch dễ dàng hơn rất nhiều.

Tôi mạnh mẽ đồng ý với Kirill và nói chung mã không nên biết thực tế là nó đang được kiểm tra (trong trường hợp của bạn có lẽ bạn có thể vượt qua ràng buộc/kết nối db của bạn thông qua một hàm tạo?), Tôi có thể thấy lý do tại sao bạn có thể muốn phát hiện điều này.

+6

Lý do duy nhất tôi cần kiểm tra xem ứng dụng có đang chạy thử nghiệm hay không là kiểm tra xem tôi có được kết nối với cơ sở dữ liệu sản xuất hay không, bởi vì các thử nghiệm sẽ xóa cơ sở dữ liệu. Chỉ là hoang tưởng thuần khiết, bởi vì nó sẽ không bao giờ xảy ra - nhưng trong 30 năm trong kinh doanh này, tôi đã thấy rất nhiều điều sai trái đã được tuyên bố là "điều đó sẽ không bao giờ xảy ra". –

Các vấn đề liên quan