So I'm starting with the code we had before that works correctly, except for,
with this assumption that all months have 30 days. So the first step is going to
be to define the stub procedure daysInMonth that gives the number of days in a
month. But, for our stub procedure, we're just going to always return 30. And
I'm going to modify nextDay to call daysInMonth. That's pretty simple, but I
should start testing, and I'm going to write some code to do testing. We don't
want to have to keep typing the same test cases in the shell. We want to write
some code for testing. For the problem that's provided, there were some provided
test cases. I'm going to write my own starting now. And I'm going to make sure
that these test cases, we don't expect the correct results yet because I'm
testing with 30-day months. So, I'm going to test two dates that are the same.
It's a boundary case, it's a useful one to test. I'm going to test from one day
to the next, that should give us one day. And these are test cases for days
between dates. I should really be writing some test cases for next day. The
reason for that is that, if they fail, well, it's going to be more easy to
understand what went wrong, rather than just writing all of my test cases for
days between days. So let's try some nextDay test cases. Got one where the day
advances. Let's get one where the month advances. And I will use a month that
has 30 days. So it will be correct in 30 months, but will still be correct once
we fix this. And I'll use advancing the year. A few test cases, probably we
should have more. But let's try that. We should save, and let's run this, and
we'll run our test. And, something failed. Not too surprising, this happens.
Let's see what failed. And the failure is type error that I'm calling
daysInMonth Not passing in the right number of parameters. In fact, I passed in
0. I should have passed in both the year and the month. So this is one of the
reasons for writing things in stubs, we can find these kinds of errors quickly.
So let's try again, and now we're test passed, and our test case is using
restrictions. I'm going to be a little more careful and print something out when
the test finishes, because it's a little bit dangerous to have nothing to tell
when the test finished. Maybe we didn't get any output for some other reason.
Entonces, inicio con el código anterior que funcionaba correctamente, excepto
con esta suposición de que todos los meses tienen 30 días. El primer paso
va a ser definir el trozo de procedimiento dayInMonth que da el número de días en
un mes. Pero, para nuestro trozo de procedimiento, sólo vamos a retornar siempre 30 días. Y
voy a modificar nextDay para llamar daysInMonth. Que es muy sencillo, pero
debo iniciar probando, y voy a escribir código para hacer la prueba. No
queremos estar escribiendo los mismos casos de pruebas en el intérprete. Queremos escribir
código para probar. Para el problema que es proporcionado, había
casos de prueba proporcionado. Voy a escribir el mío a partir de ahora. Y voy a estar seguro
que en estos casos de prueba, no esperamos aún los resultados correctos porque
estoy probando con 30 días en meses. Entonces, voy a probar dos fechas que son iguales.
Es un caso fronterizo, es útil uno para probar. Voy a probar desde un día
al siguiente, que debe darnos un día. Y estos son casos de pruebas para días
entre fechas. Debo realmente escribir algunos casos de prueba para el siguiente día.
La razón por la cual es esa, es que si fallamos, bueno, va a ser más fácil
entender en que fallamos, antes que sólo escribir todos mis casos de pruebas para
días entre días. Intentemos algunos casos de prueba nextDay, Conseguiste uno donde el día
avanza. Consigamos uno donde el mes avanza. Y usaremos un mes que
tiene 30 días. Por lo tanto sería correcto en 30 meses, pero será todavía correcto una vez que
arreglemos esto. Y usaré el año siguiente. Unos pocos casos de prueba, probablemente
debemos tener mas. Pero intentemoslo, Debemos grabar, y ejecutamos esto, y
ejecutará nuestra prueba. Y, algo fallará. No tan sorprendente, esto ocurre.
Veamos que falló. Y el fallo es el error de escritura que voy llamando
daysInMonth No pasa el número correcto de parámetros. De hecho, pasé en
0. Debo haber pasado ambos, el año y el día. Entonces esta es una de las
razones por escribir cosas en trozos, podemos hallar este tipo de errores rápidamente.
Intentemos de nuevo, y ahora estamos pasando la prueba, y nuestro caso de prueba está usando
restricciones. Voy a ser un poco cuidado y mostrar cuando
la prueba termina, porque es un poco peligroso no tener que decir
cuando la prueba termina. Tal vez, no obtuvimos salida por alguna razón.
正確に機能したコードから始めます
ただしすべての月が30日であるという仮定は除きます
第1ステップは月の日数を与える スタブ関数のdaysInMonthを定義することです
しかしこのスタブ関数では常に30を返します
daysInMonthを呼び出すためにnextDayを修正します これはとても簡単です
ですがテストする必要があり テスト用のコードを書きます
シェルに同じテストケースを入力し続けたくありません テストするコードを書きます
与えられた問題では与えられたテストケースが いくつかありました
では私のコードを書き始めます これらのテストケースを確認します
月が30日のものをテストしているので 正確な結果はまだ望めません
同じ2つの日付をテストします
これはテストする時に役立つ境界ケースです ある日からその翌日までテストします
これで1が与えられるはずです これは日付間の日付のテストケースです
nextDayのテストケースを書く必要があります
なぜなら日付間の日付の テストケースだけを書くよりは
失敗した時に何が誤っていたのか 理解しやすくなるからです
nextDayテストケースを試してみましょう 前の日の日付を取得しましょう
前の月の日付を取得しましょう すべての月は30日間とします
30ヵ月に直します これは一度修正したら正しいままのはずです
前の年を使います テストケースは おそらくもっとあるはずですがこれを試してみましょう
保存する必要があります これを実行しましょう
テストを実行すると何かが失敗しますが 特に驚くことではありません
何が失敗したのか確認してみましょう 失敗はタイプエラーでした
正しいパラメータの数値を渡さずに daysInMonthを呼び出しています
実際私はゼロを渡しました yearとmonth両方を渡すべきだったのです
これがスタブで書く理由の1つです このようなエラーをすぐに見つけることができます
もう一度試してみましょう 今回のテストはうまくいきました
私たちのテストでは制限条件が使われています
テストを終える際はよく注意して出力します 終了しても何も分からないのは少し危険です
おそらく何か別の理由で出力が得られませんでした