Posted on

Code Dojos

Learning continuously is important in our rapidly changing business to avoid being outlived by the latest technology or style. I guess most of our readers come to clean-cpp.org because they are interested to learn something new about C++ they did not know before, or they like the good feeling to read that someone else thinks what they are already doing is right. Besides reading blogs and books, there are a few things one can do to stay up to speed:

  • Write a blog on your own. You would be surprised what you need to learn in order to write an article.
  • Visit talks or watch them on Youtube or other video platforms.
  • Join an open source community and start working on a project you like.
  • Learn a new programming language.
  • Browse through someone else’s code.
  • Talk to someone who is a better programmer than you are.

A code dojo is a relatively new practice of learning from another, and it combines some of the best features of above list. Basically, it is an informal gathering of programmers. Together, they write code to solve a fun task. They talk with each other, drink beer, and eat pizza. It is almost like a night out, but with more code.

Continue reading “Code Dojos”

Posted on

Mock objects

Unit tests follow a simple pattern. First, you create a controlled environment for the function or class you want to test. Afterwards, you call a function or method of an object or create a new instance. Finally, you assert that the function returns the expected value or the state of your object has changed as desired. Sometimes, though, tests seem to grow unnaturally large because it is ridiculously difficult to control the environment.

Quite often the issue is that the code you would like to test is too specialized to be easily testable. In this article we will learn about how interfaces and mock objects can be used to enhance the testability of your code and make it easier to reuse.

Continue reading “Mock objects”

Posted on

Test-driven development

In an earlier article I discussed the merits of unit tests. In essence, unit tests are pieces of code which assert that your production code works as intended. With a sufficient amount of unit tests it is possible to refactor your production code at any time, because the safety net of knowing when you broke something gives you courage.

Typically, programmers write code and test it afterwards. Code which is not easily unit testable is not tested or integration tested. Execution paths are overlooked, boundary cases get ignored. There is not much safety for future changes, because there is no machine-executable specification of how less well-known regions of the code are supposed to behave. Enter test-driven development (TDD).

Continue reading “Test-driven development”