--===============1030327527== Content-Type: multipart/alternative; boundary="===============7907008327078239400==" --===============7907008327078239400== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On 2010-09-10 15:41:36, Thomas Zander wrote: > > Please provide a unit test to show the problem. > = > 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. > = > Pavol Korinek wrote: > To simulate this problem I had to combine tests for application (KWTe= xtDocumentLayout) 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 Mo= ck object of KWTextDocumentLayout or Layout.cpp for this test is not possib= le, because part of functionality which I need is connected to so many othe= r fuctionallity, that it's not possible to cut some. At least if I was succ= essfull with this test, and had sucessfull simulation, than run of such tes= t, was like run application with test data and check output. I suggest more= people to check KWTextDocumentLayout logic and check if firstParagraph boo= lean value, should be set to true, when new shape comes into play. > = > Thomas Zander wrote: > The Layout plugin and the KWTextDocumentLayout are indeed two separat= e units, and should be tested separately. This is possibly by defining the= interactions between the two and figuring out what you expect to happen wh= ich 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 th= e contract of the APIs since you say you need both at the same time. That m= ay be a good place to start. > = > Also, I think there are various partners listed on the Qt website tha= t provide training for writing unit tests, if you and your company lacks th= at 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, f= or free, to a for-pay subcontractor. > = > Carlos Licea wrote: > Thomas, please, please, behave as good as you can. If you lack the te= mper 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 streng= th when you act in this way. We all can be rude, let's try not to. > = > 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 e= mails 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 t= o write unit tests for the simple reason he is a consultant that is hired f= or 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 teac= h him how to do his job. I bet you would not put in your time to do that ei= ther. > = > 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 ye= ars 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 t= o archive great software. - Carlos ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5305/#review7526 ----------------------------------------------------------- On 2010-09-13 07:19:03, Pavol Korinek wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/5305/ > ----------------------------------------------------------- > = > (Updated 2010-09-13 07:19:03) > = > = > Review request for KOffice. > = > = > Summary > ------- > = > We use shape (m_state->shape) height to set 'end bottom position' when fi= rst paragraph occurs. When m_state->shape is new one, then we should set ne= w 'end bottom position'. It can be done by set firstParagraph to true on ne= w shape. This was investigated to solve: https://bugs.kde.org/show_bug.cgi?= id=3D239703 > = > = > Diffs > ----- > = > /trunk/koffice/kword/part/frames/KWTextDocumentLayout.cpp 1172979 = > = > Diff: http://svn.reviewboard.kde.org/r/5305/diff > = > = > Testing > ------- > = > = > Thanks, > = > Pavol > = > --===============7907008327078239400== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://svn.reviewb= oard.kde.org/r/5305/ |
On September 10th, 2010, 3:41 p.m., Thomas = Zander wrote:
Please pr= ovide a unit test to show the problem.On September 13th, 2010, 8:44 a.m., Thomas Zander wrote:
Thanks fo= r explaining how to load a document and see it fail; this is black box test= ing and useless for regression testing or showing the actual bug in the cod= e. Please provide a unit test to show the problem.On September 17th, 2010, 1:42 p.m., Pavol Korinek wrote:
To simula= te this problem I had to combine tests for application (KWTextDocumentLayou= t) 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 a= lso, because they are invisible one to each other. Also to create Mock obje= ct of KWTextDocumentLayout or Layout.cpp for this test is not possible, bec= ause part of functionality which I need is connected to so many other fucti= onallity, that it's not possible to cut some. At least if I was success= full 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 pe= ople to check KWTextDocumentLayout logic and check if firstParagraph boolea= n value, should be set to true, when new shape comes into play.On September 21st, 2010, 3:38 p.m., Thomas Zander wrote:
The Layou= t plugin and the KWTextDocumentLayout are indeed two separate units, and sh= ould be tested separately. This is possibly by defining the interactions b= etween 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 t= est based on that conclusion; you either write a test that tests the provid= er 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 prov= ide training for writing unit tests, if you and your company lacks that kno= wledge 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, p= lease, please, behave as good as you can. If you lack the temper please con= sider contacting a counselor; I, as a paid consultant, can't go consult= ing emotions, while I'm at my work, for free. Your reviews, not matter how good or right they are, lose much strength whe= n 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 Carlo= s, the story is easier than assuming I'm unstable and not making sense; th= ere is a perfectly logical reason for the sentence I wrote. The facts are that Matus doesn't have the experience in writing unit te= sts 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 o= n 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 w= ant to focus on the fun things and get KWord better prepared for the next 1= 0 years of its lifetime :)
I do unders= tand 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:
Review request for KOffice.
By Pavol Korinek.
Updated 2010-09-13 07:19:03 Descripti= on
Diffs=
|