Thanks for your letter!
Of course, we know TDD principles. But there was such trouble - the project existed before us and it was not contain unit tests. Some tests for PDF creation and conversion existed but it was not unit tests. Code was not very good and unit tests writing “as is” wasn’t possible for the most part. When we reorganize code unit testing became possible. Now we are writing tests before coding in the main (depends on mood and tasks )

Best regards,
Vitaliy Shibaev!

I found your blog entry while searching what would be the best option for unit testing in C++. I already knew about cppunit and Boost test but I was quite lost in the ‘C++ Unit Testing Framework Jungle’. The links you provided seems a good starting point. Thanks.

I thought I would drop a comment because of this sentence “One of our refactoring goals was to improve testability of the code”. I understand your point but I am used to read it the other way around. In “test driven development”, the first step is testing and testing is a way to improve design. It seems like your team is not using this method of designing software but you might want to know more about it.

regards

Bertrand Dechoux

We aren’t divide refactoring and code writing - always try to write good new code. Because our library contains some bad code from old-old version sometimes we only refactor code all day long.
Refactoring (in aggregate with architecture projecting) is creative work undoubtedly. See how the code is becoming better - it’s delicious
Of course sometimes needs some routine actions, it’s normal.

Best regards,
Vitaliy Shibaev!

I’m a Java developer. After reading of Fowler I use JUnit Tests in my projects. I think that a self tested code is important for refactoring. So your notes are interesting for C++ developers.

Vitaly, how much time (percentagewise) do you deal with refactoring in development process? Do you think that refactoring is creative work or it’s rather a routine for developers?

First you need always remember main goal of refactoring - it is code clarity. Look at your code and ask yourself - how I can make it more clear? Imagine resulted code and think over process to achieve that result, divide it on elementary steps, such as Extract method, Rename method etc. Each step must not change program behavior, so unit tests is very useful. With experience you will make it automatically, without remembering names of Fowler’s refactorings.
Undoubtedly the most frequently used refactoring is Extract method (with good method name).

I advise you necessarily read these books (if didn’t read as yet) - “Refactoring” (M. Fowler) and “Code Complete” (S. McConnell).
Concerning me - I permanently refactor my code since reading Fowler’s book, about 1.5 years.

Best regards,
Vitaliy Shibaev!