Skip to content

Category: TDD

  • warning: Creating default object from empty value in /home/artemmarchenko/ on line 33.
  • strict warning: Non-static method view::load() should not be called statically in /home/artemmarchenko/ on line 823.
  • strict warning: Declaration of views_plugin_display::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/ on line 1684.
  • strict warning: Declaration of views_plugin_display_page::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 457.
  • strict warning: Declaration of views_plugin_display_block::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 184.
  • strict warning: Declaration of views_handler_field_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 243.
  • strict warning: Declaration of views_handler_sort_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 82.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/artemmarchenko/ on line 584.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/artemmarchenko/ on line 584.
  • strict warning: Declaration of views_handler_filter_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 608.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/ on line 61.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 61.

CppUTest framework. Symbian extension and example

October 2, 2007 by Artem Marchenko

Update: The users of some a bit exotic SDKs reported that they cannot build the example. The reason was the project file SampleTest.mmp. I updated it making the project file a bit redundant. Now example should be compilable on any S60 SDK.

CppUTest is a unit testing framework based on CppUnitLite and designed for the embedded systems usage. Lately it has been ported to Symbian OS used in Nokia S60 smartphones. The framework is xUnit compatible, extremely simple and easy to use. It can print the test results both to console and to a junit-like xml file (later I am going to investigate how well it can be parsed by standard junit output parsers).

Symbian extension. Usage example

Unfortunately, CppUTest package at the moment does not include a full-blown Symbian specific example and lacks support for such Symbian primitives as descriptors (Symbian strings) and leaves (Symbian exceptions).

The file attached to this post contains both. It is a simple and heavily commented example of using CppUTest in Symbian, that includes cpputestsymbianextension.h adding support for descriptors and leaves.

Agile-aware C++ IDE

March 9, 2007 by Artem Marchenko

A colleague of mine lately asked me what would be the most important C++ IDE features for supporting the agile software development. While agile processes are more about people and interaction, than about the tools, a decent tool support certainly makes things easier. Here is a list of things I would value in the agile-aware C++ IDE in the order of decreasing priority.

1. Command-line repeatability
Agile methods see the high levels of automation of a ‘mechanical’ and repetitive tasks as a relief for the developers and help to reduce errors.

We have to be good at being wrong. Architects can help

April 28, 2006 by Artem

Anssi Piirainen raises the idea about the need to be good at being wrong in order to create good software. The core idea is good - you have to be ready that the first implementations might later look not very well. However, Anssi also presents the micro case study describing the problems with the "just-in-time design" approach. The changes required appeared to be unexpectedly difficult to not that experienced programmers.

Just-in-time design is not a silver bullet. It is just yet another good tool that can be rather useless until it is used with the correct support practices.

Mocks, stubs and fakes

April 25, 2006 by Artem

I am rather new to the Test-Driven-Development (TDD) and continuous testing in general. Therefore I quite often experience the terminology difficulties: how to call fully functional alternative object, how to call almost empty stub objects, etc. It looks like I am not alone.

Martin Fowler highlights the Gerard Meszaros's proposal:

The generic term he uses is a Test Double (think stunt double). Test Double is a generic term for any case where you replace a production object for testing purposes. There are various kinds of double that Gerard lists:

Selling Test-Driven Development to your boss

March 29, 2006 by Artem

Managers don't speak C++, refactoring and some of them don't trust the programmer's "feelings". To sell TDD to them, we have to speak the management language of costs, deadlines and delivery delays. Apply some management language and you'll be able to start the TDD.

Killer argument tips:
1) Extra testing saves at least some time of the final test round
2) Extra testing improves the code quality at least a bit
3) If extra testing is applied to the most important components and interactions, it takes not that scary amount of time
Therefore even in the worst case the time spent on the extra testing will be partially compensated with the better quality and smaller final testing efforts. And in the best case, both quality and delivery time will be improved significantly.

Testability as the design metric

March 26, 2006 by Artem

I don't care how good you think your design is. If I can't walk in and write a test for an arbitrary method of yours in five minutes its not as good as you think it is, and whether you know it or not, you're paying a price for it. (Michael Feathers)

If you practice a lot of unit testing, test-driven-development of whatever method that includes a lot of testing, you have to spend a lot of time on it. And most of time you have to do the testing-related work before the problem happens and before anyone is affected. Certainly it is good to capture the bug early, before it hurts anybody, but the need to do the "extra" work in advice introduces the temptation to "just tweak this small feature and test it if the problem arises later".

Do you own your code?

March 8, 2006 by Artem

When there are more, than one programmer on the project, the work has to be divided somehow. Agile methodologies propose self-organized team to decide who is doing what, more traditional waterfall approaches propose that manager allocates tasks to the guys with the free time slots. Whatever the method is, there is one more thing to consider: who is allowed to make changes where.
It is quite often that particular modules are "owned" by particular people and only they are allowed to make reasonable changes there. Usual argument is "The person, who doesn't know the module, can unintentionally break it".

Best of