2010-06-17 54 views

回答

2

當我讀到他的問題時,我認爲它是如何確保send_data發送了字符串/他所要求的任何內容。不是爲了測試它的發送,而是爲了確保他放心,他發送的方法並不是空白。嘲笑,正如你所做的那樣,並不能真正爲他帶來那樣的結果。

也許你可以確保你的字符串不是空白的,或類似的東西。這樣你就不會測試send_data,但是無論send_data是什麼,都是你想要的樣子。

在我的情況下(什麼給我帶來了這個問題)是

#just use this to make sure it looks like you want it to while you are writing your 
#tests. I remove it after. make sure it's an instance variable @csv_string in my case. 
puts assigns(:csv_string) 

refute_nil assigns(:csv_string) #does the actual work. delete the puts line when done. 

一些票友人使用Ruby調試和sh!的...您的里程會有所不同。

+0

控制器測試是關於模擬。如果您需要「真實」的東西,請進行集成測試。如果你願意,下面的解決方案實際上就是「rspec方式」。 – yiwen 2012-05-16 00:12:35

+0

控制器測試是關於模擬?奇數聲明和更糟的是,反對票。當你嘲笑它時,你並沒有測試任何東西,只是send_data被調用的事實,並且它繼續工作。在我的例子中,正如OP所說,我們正在測試send_data實際上是在做它的工作。一塊心靈的測試。 – pjammer 2012-05-16 01:31:34

+0

對此使用集成測試。單元測試不適用於測試send_data作品。 – yiwen 2012-05-31 20:05:04

9

您不應該需要測試send_data本身的行爲,主要是因爲Rails自己的測試涵蓋了該行爲。此外,它會使您的測試運行緩慢(最終)。你應該做的(從我的角度)是存根SEND_DATA方法是這樣的:

controller.expects(:send_data).with("foo").returns(:success)

希望它能幫助。

+4

我不建議這樣做。嘲笑你不擁有的代碼通常不是一個好主意。如果'send_data'的API發生變化(比如Rails升級),你就不會知道你的代碼被破壞了。 – 2014-07-05 17:23:04

+3

@XavierShay這是非常值得商榷的。你不擁有的模擬和存根代碼通常被認爲是真正的單元測試的唯一好方法。然而,「上游可能改變」是你想要在測試中抓住的東西。但不是在單元測試中。你應該爲此進行集成測試。 (這就像你的觀點一樣,只是一個觀點,有很多) – berkes 2015-03-23 08:29:57

+0

「你不擁有的模擬和存根代碼通常被認爲是進行真正的單元測試的唯一好方法。」參考?我想詳細瞭解這項工作對於人們來說(長期)有效。爲了支持我自己的斷言:http://www.jmock.org/oopsla2004.pdf以及https://www.google.com/?#safe=active&q=only+mock+types+you上的一小部分結果+自己 – 2015-03-23 16:36:54

3

您可以通過檢查標頭的值Content-Transfer-Encoding間接測試它。

 
expect(controller.headers["Content-Transfer-Encoding"]).to eq("binary") 

 
controller.headers["Content-Transfer-Encoding"].should eq("binary") 
+0

控制器未定義 – nathanengineer 2016-06-30 03:29:46

+0

@glochild可能是'@ controller'會爲你工作 – prasvin 2016-07-08 10:19:19