readme.md

Step 4. Loop: Implement Dockerfile, Make Tests Pass, Refactor!

In Step 3 we made one test pass, with one line in our Dockerfile.

4a. The Loop

Now its a matter of repeating the loop:

1. Implement a pending test;
2. Execute tests and it fails;
3. Write further instructions in your Dockerfile;
4. Execute tests and it passes;
5. Repeat

4b. Final Specs

Take a look at the file specs/Dockerfile_specs.rb for the full suite of implemented tests.

4c. Final Dockerfile

See Dockerfile.

4d. Refactor!

The Dockerfile_specs.rb is definitely not in an optimal state. You can refactor it as needed, all the time following the above loop.

My TDD Journey

My journey to making tests pass looked something like this:

1 Passed, 1 Failed, 3 Pending

2 Passed, 3 Pending

2 Passed, 1 Failed, 2 Pending

3 Passed, 2 Pending

Nearly There! 4 Passed, 1 Pending!

All Passed! ✔️ ✔️ ✔️ ✔️ ✔️

Known Issue - java -version output goes to stderr instead of stdout

• Open the Dockerfile_spec.rb in this directory.
• Look at the helper method java_version. It returns the stderr of the command java -version, not the stdout. Why is this?
• The answer is in this Github issue discussion.
• Long story short: java -version output is sent to stderr. This has been known since the year 2000 and likely will never change.

Our Dockerized Petclinic App!

During the testing process, our tested Docker image has been created, savishy/tomcat-petclinic-tdd.

Run a container off the image:

docker run -p 8080:8080 savishy/tomcat-petclinic-tdd

Open http://localhost:8080 in a browser.

Next Steps

Certainly this is not "the end" of our TDD journey.

1. Can you figure out how to develop tests for the running container?
2. More tests can certainly be added - for example:
   1. to verify the application port
   2. to verify the image layer counts etc.
3. And the spec/Dockerfile.rb file is not optimal. How would you peel out the helpers into a separate directory?

Go figure it out!