tests building

[Maximilian Kossick]

On Thu, Jan 21, 2010 at 10:49 PM, Ian Monroe <ian.monroe at gmail.com> wrote:
> On Thu, Jan 21, 2010 at 3:38 PM, Maximilian Kossick
> <maximilian.kossick at googlemail.com> wrote:
>> On Thu, Jan 21, 2010 at 10:24 PM, Ian Monroe <ian.monroe at gmail.com> wrote:
>>> On Thu, Jan 21, 2010 at 3:12 PM, Maximilian Kossick
>>> <maximilian.kossick at googlemail.com> wrote:
>>>> What was inaccurate?
>>>>
>>>
>>> The result of tests with stub functions.
>>>
>>
>> Not quite, as the tests still ensure that one part of the externally
>> observable behaviour of the class under test stays the same. As unit
>> tests are white box tests, the developer is able to judge at the time
>> of writing whether doing anything more than just reimplementing the
>> function for the sake of making the linker happy is required. If the
>> internal behaviour of the class under test changes, the test might
>> catch that or you have an incomplete test which does not verify all
>> side effects of the class under test. Which is still *way* better than
>> no test.
>
> I kind of see what you're saying. But just throwing in stub functions
> to satisfy the requirements of the Linux linker (what is the Mac
> linker using...?) doesn't seem like anyone is making a judgement.
>
>
>> Ideally we'd just get rid of all those static methods...
>
> Why do you say that, static methods are faster to call and often good design.
>

Yep, simple utility functions that do not have any state can stay that
way. A good reason to not let them stay that way is being able to test
code that uses them. By putting them into some dumb object, you are
able to mock that object and return any value that is required to test
the classes the utility functions/methods.

More of a problem is actually that a lot of the functions in Amarok.h
are defined in App.cpp for some reason. That really needs to be fixed.