可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I am not understanding how the TDD FIRST principle isn't being adhered to in the following code.

These are my notes about the FIRST principle:

Fast: run (subset of) tests quickly (since you'll be running them all the time)

Independent: no tests depend on others, so can run any subset in any order

Repeatable: run N times, get same result (to help isolate bugs and enable automation)

Self-checking: test can automatically detect if passed (no human checking of output)

Timely: written about the same time as code under test (with TDD, written first!)

The quiz question:

Sally wants her website to have a special layout on the first Tuesday of every month. She has the following controller and test code:
# HomeController  def index    if Time.now.tuesday?      render 'special_index'    else      render 'index'    end  end   # HomeControllerSpec  it "should render special template on Tuesdays" do    get 'index'    if Time.now.tuesday?      response.should render_template('special_index')    else      response.should render_template('index')    end  end 
What FIRST principle is not being followed?

Fast

Independent

Repeatable

Self-checking

Timely

I'm not sure which FIRST principle is not being adhered to:

Fast: The code seems to be fast because there is nothing complex about its tests.
Independent: The test doesn't depend on other tests.
Repeatable: The test will get the same result every time. 'special_index' if it's Tuesday and 'index' if it's not Tuesday.
Self-checking: The test can automatically detect if it's passed.
Timely: Both the code and the test code are presented here at the same time.

I chose Timely on the quiz because the test code was presented after the controller code. But I got the question wrong, and in retrospect, this wasn't a good choice. I'm not sure which FIRST principle isn't being followed here.

回答1:

It's not Repeatable as not everyday is Tuesday :) If you run this test on Monday you will get one result, if you run it on Tuesday, a different one.

回答2:

Independent and Repeatable

It is not independent from date and then it would able to run repeat but technically you get the same result because you choose to

The proper way to make a test for HomeController regarding to FIRST concept is change the time before the evaluation stage

回答3:

Yes, the confusion partly has the reason, that the F.I.R.S.T. principle is not complete or concise enough concerning the "I". In courses I attended the principle was called F.I.I.R.S.T.

The second "I" stands for "Isolated". The test above is independent from other tests, but is not isolated in a separate class or project.

[Updated]:

Isolation can mean:

A unit tests isolates functionality out of a SUT (system under test). You can isolate functionality even out of one single function. This draws the line between unit tests or their relatives component tests and integration tests, and of course to system tests.
"Tests isolate failures. A developer should never have to reverse-engineer tests or the code being tested to know what went wrong. Each test class name and test method name with the text of the assertion should state exactly what is wrong and where." Ref.: History of FIRST principle
A unit test could be isolated from the SUT which it tests in a different developer artifact (class, package, development project) and/or delivery artifact (Dll, package, assembly).
Unit tests, testing the same SUT, especially their containing Asserts, should be isolated from each other in different test functions, but this is only a recommendation. Ideally each unit test contains only one assert.
Unit tests, testing different SUTs, should be isolated from each other or from other kind of tests of course further more in different classes or other mentioned artifacts.

Independence can mean:

Unit tests should not rely on each other (explicit independency), with the exception of special "setup" and "teardown" functions, but even this is subject for a discussion.
Especially unit tests should be order-independant (implicit independency). The result should not depend on unit tests executed before. While this sounds trivial, it isn't. There are tests which cannot avoid doing initializations and/or starting runtimes. Just one shared (e.g. class) variable and the SUT could react differently, if it was started before. You make an outside call to the operating system? Some dll will be loaded first time? You already have a potential dependency, at least on OS level- sometimes only minor, sometimes essential to not discover an error. It may be necessary to add cleanup code to reach optimal independency of tests.
Unit tests should be independant as much as possible from the runtime environment and not depend on a specific test environment or setting. This belongs also partly to "Repeatable". No need to fillout twenty user dialogs before. No need to start the server. No need to make the database available. No need for another component. No need for a network. To accomplish that, often test doubles are used (stubs, mocks, fakes, dummies, spies, ..).

(Gerard Meszaros' classic work on: xUnit patterns, here coining the name 'test double' and defining different kinds of)

(Test double zoo quickly explained)

(Follow Martin Fowler 2007, thinking about stubs, mocks, etc. Classic)
While a unit test is never totally independant from it's SUT, ideally it should be independant as much as possible from the current implementation and only rely on the public interface of the function or class tested (SUT).

Conclusion: In this interpretations the word 'isolation' stresses more the physical location which often implies logical independence to some extent (e.g. class level isolation).

No completeness concerning potentially more accentuations and meanings claimed.