On September 10th, 2010, 3:41 p.m., Thomas Zander wrote:

Please provide a unit test to show the problem.

On September 13th, 2010, 8:44 a.m., Thomas Zander wrote:

Thanks for explaining how to load a document and see it fail; this is black box testing and useless for regression testing or showing the actual bug in the code. Please provide a unit test to show the problem.

On September 17th, 2010, 1:42 p.m., Pavol Korinek wrote:

To simulate this problem I had to combine tests for application (KWTextDocumentLayout) and pluggin (Layout.cpp) which means don't write test for some unit or function, but test for whole layout. It's not possible to mix them also, because they are invisible one to each other. Also to create Mock object of KWTextDocumentLayout or Layout.cpp for this test is not possible, because part of functionality which I need is connected to so many other fuctionallity, that it's not possible to cut some. At least if I was successfull with this test, and had sucessfull simulation, than run of such test, was like run application with test data and check output. I suggest more people to check KWTextDocumentLayout logic and check if firstParagraph boolean value, should be set to true, when new shape comes into play.

On September 21st, 2010, 3:38 p.m., Thomas Zander wrote:

The Layout plugin and the KWTextDocumentLayout are indeed two separate units, and should be tested separately.  This is possibly by defining the interactions between the two and figuring out what you expect to happen which doesn't happen right now.
After defining the interaction and deciding which of the two sides is buggy (either the provider of the API or the user of the API) you write a unit test based on that conclusion; you either write a test that tests the provider of the API or you write a test testing the consumer of the API.

In your explanation it seems you don't have a clear picture yet of the contract of the APIs since you say you need both at the same time. That may be a good place to start.

Also, I think there are various partners listed on the Qt website that provide training for writing unit tests, if you and your company lacks that knowledge please consider contacting them. I'm have to be honest in that I don't really have the time to explain those concepts in my spare time, for free, to a for-pay subcontractor.

On September 23rd, 2010, 5:42 a.m., Carlos Licea wrote:

Thomas, please, please, behave as good as you can. If you lack the temper please consider contacting a counselor; I, as a paid consultant, can't go consulting emotions, while I'm at my work, for free.

Your reviews, not matter how good or right they are, lose much strength when you act in this way. We all can be rude, let's try not to.

On September 23rd, 2010, 8:44 a.m., Thomas Zander wrote:

Hey Carlos,

the story is easier than assuming I'm unstable and not making sense; there is a perfectly logical reason for the sentence I wrote.
The facts are that Matus doesn't have the experience in writing unit tests that show the bug is actually where he thinks it is and I'm getting emails from his customer that I should teach him this to be able to work on KOffice.

I'm just being very clear I have no intention of teaching Matus how to write unit tests for the simple reason he is a consultant that is hired for his expertise and I'm a volunteer programmer working on KWord for fun.

Compare this to someone trying to fix your car and you having to teach him how to do his job. I bet you would not put in your time to do that either.

As a smart man wrote; "focus is deciding what not to do". And I want to focus on the fun things and get KWord better prepared for the next 10 years of its lifetime :)

I do understand your reasoning and I do agree that a test is, probably, the best thing to do, so that the expected behavior gets documented. My point is not that you're "unstable," but that we don't need to be rude in order to archive great software.

- Carlos

On September 13th, 2010, 7:19 a.m., Pavol Korinek wrote:

We use shape (m_state->shape) height to set 'end bottom position' when first paragraph occurs. When m_state->shape is new one, then we should set new 'end bottom position'. It can be done by set firstParagraph to true on new shape. This was investigated to solve: https://bugs.kde.org/show_bug.cgi?id=239703