You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by rey malahay <re...@gmail.com> on 2011/09/03 23:02:23 UTC
Mocking Frameworks
Dear PDFBox Team,
May I use a mocking framework in my unit tests? I am currently using Mockito
in conjunction with JUnit, to write my unit tests and mock classes that do
not form part of the test objective. If so, how do we include the framework
in question with our patch submission?
Please advise.
Thanks in advance,
Rey Malahay
--
My heroes are the ones who survived doing it wrong, who made mistakes, but
recovered from them. - Bono
Re: Mocking Frameworks
Posted by rey malahay <re...@gmail.com>.
Thanks Guys, point taken.
On 7 September 2011 08:13, Martinez, Mel - 1004 - MITLL <
m.martinez@ll.mit.edu> wrote:
> Just a couple of quick comments.
> -----Original Message-----
> From: rey malahay [mailto:reymalahay@gmail.com]
>
> >
> > If it is a question of writing quality/ better code, then adding another
> > library that supports the quality objective should not be a big deal. The
> > last time I checked, the Apache Software Foundation was all about
> > meritocracy. I believe that I am just doing my bit to uphold that value.
>
> The interests Adam alluded to extend beyond just the direct interests of
> the
> ASF. Adding any new third party code or package is often a very, very big
> deal for those of us who depend on ASF components such as PDFBox. It
> creates work in order to pass testing and accreditation and to do all
> necessary paperwork. If something costs work then the benefit needs to be
> at least proportional to the cost.
>
> There are many good reasons to enable use of mock objects/doppelgangers for
> unit testing so I don't want to imply that I don't advocate for that.
> However the disadvantages of including yet-another-package in the
> distribution outweigh the benefits, imho. Good design patterns can enable
> mock testing without a framework (and of course, poor designs can preclude
> it even with a framework).
>
> The committers have final say, but I vote -1 on adding a mocking framework
> to the PDFBox testing harness.
>
>
>
>
--
My heroes are the ones who survived doing it wrong, who made mistakes, but
recovered from them. - Bono
Re: Mocking Frameworks
Posted by rey malahay <re...@gmail.com>.
Thanks for upholding the ASF's principles, Jukka.
On 8 September 2011 01:31, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Wed, Sep 7, 2011 at 4:13 PM, Martinez, Mel - 1004 - MITLL
> <m....@ll.mit.edu> wrote:
> > The interests Adam alluded to extend beyond just the direct interests of
> the
> > ASF. Adding any new third party code or package is often a very, very
> big
> > deal for those of us who depend on ASF components such as PDFBox.
>
> Note that a testing tool is by definition not included in the jar
> artifacts used downstream, so their licensing impact is minimal. The
> only problem is if the license of the testing tool would virally
> affect the license of the test code within PDFBox, but that won't be
> the case at least with the MIT-licensed Mockito.
>
> > However the disadvantages of including yet-another-package in the
> > distribution outweigh the benefits, imho.
>
> I disagree based on the above point. Better testing tools help improve
> quality and their impact on licensing is minimal.
>
> So, FWIW, +1 to using a mock tool in unit tests.
>
> BR,
>
> Jukka Zitting
>
--
My heroes are the ones who survived doing it wrong, who made mistakes, but
recovered from them. - Bono
Re: Mocking Frameworks
Posted by Adam Nichols <mr...@gmail.com>.
+1 for the mocking framework. :-)
On Fri, Sep 9, 2011 at 10:41 AM, Martinez, Mel - 1004 - MITLL
<m....@ll.mit.edu> wrote:
> That sounds reasonable. I fully concur that our project's audit and
> oversight level is not the norm. We thus already accept that we have more
> work to do in dealing with added dependencies than normal. This isn't just
> in regards to PDFBox, btw.
>
> My expression of concern here is in the spirit of "If I can avoid increasing
> that work, I will!" :-D
>
> The truth is, given the time frames, I'm really looking out for someone else
> who will end up with that work dumped on them. I would not be a good team
> player if I didn't advocate for conservatism on this point.
>
> Mel
>
> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: Friday, September 09, 2011 9:49 AM
> To: dev@pdfbox.apache.org
> Subject: Re: Mocking Frameworks
>
> Hi,
>
> On Fri, Sep 9, 2011 at 3:19 PM, Martinez, Mel - 1004 - MITLL
> <m....@ll.mit.edu> wrote:
>> Jukka - It isn't about what I 'want' to go through.
>
> Yeah, sorry for picking on you specifically. My point is that what
> you're describing is a rather high level of oversight that isn't
> mandatory or even desirable for the average PDFBox user. Thus while I
> do understand your reluctance on new dependencies (even test ones), in
> the bigger picture it seems to me like a rather marginal concern when
> balanced against the potential benefit to all PDFBox users through
> better test coverage.
>
>> As I said before, the committers have final say, not I. If this gets
> added,
>> then when we upgrade to that version of PDFBox, we will simply have to go
>> through the necessary bureaucratic hoops.
>
> Note that PDFBox 1.7 will in any case have a lot of new code and
> dependencies thanks to the recent integration of the preflight and
> xmpbox components.
>
> Anyway, if you want to avoid the extra test dependency, I suggest you
> look at the patch Rey's planning to submit and then submit a followup
> patch that modifies the new test cases to not require the mock
> library. That's the Apache way of resolving conflicts like these.
>
> BR,
>
> Jukka Zitting
>
RE: Mocking Frameworks
Posted by "Martinez, Mel - 1004 - MITLL" <m....@ll.mit.edu>.
That sounds reasonable. I fully concur that our project's audit and
oversight level is not the norm. We thus already accept that we have more
work to do in dealing with added dependencies than normal. This isn't just
in regards to PDFBox, btw.
My expression of concern here is in the spirit of "If I can avoid increasing
that work, I will!" :-D
The truth is, given the time frames, I'm really looking out for someone else
who will end up with that work dumped on them. I would not be a good team
player if I didn't advocate for conservatism on this point.
Mel
-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
Sent: Friday, September 09, 2011 9:49 AM
To: dev@pdfbox.apache.org
Subject: Re: Mocking Frameworks
Hi,
On Fri, Sep 9, 2011 at 3:19 PM, Martinez, Mel - 1004 - MITLL
<m....@ll.mit.edu> wrote:
> Jukka - It isn't about what I 'want' to go through.
Yeah, sorry for picking on you specifically. My point is that what
you're describing is a rather high level of oversight that isn't
mandatory or even desirable for the average PDFBox user. Thus while I
do understand your reluctance on new dependencies (even test ones), in
the bigger picture it seems to me like a rather marginal concern when
balanced against the potential benefit to all PDFBox users through
better test coverage.
> As I said before, the committers have final say, not I. If this gets
added,
> then when we upgrade to that version of PDFBox, we will simply have to go
> through the necessary bureaucratic hoops.
Note that PDFBox 1.7 will in any case have a lot of new code and
dependencies thanks to the recent integration of the preflight and
xmpbox components.
Anyway, if you want to avoid the extra test dependency, I suggest you
look at the patch Rey's planning to submit and then submit a followup
patch that modifies the new test cases to not require the mock
library. That's the Apache way of resolving conflicts like these.
BR,
Jukka Zitting
Re: Mocking Frameworks
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Sep 9, 2011 at 3:19 PM, Martinez, Mel - 1004 - MITLL
<m....@ll.mit.edu> wrote:
> Jukka - It isn't about what I 'want' to go through.
Yeah, sorry for picking on you specifically. My point is that what
you're describing is a rather high level of oversight that isn't
mandatory or even desirable for the average PDFBox user. Thus while I
do understand your reluctance on new dependencies (even test ones), in
the bigger picture it seems to me like a rather marginal concern when
balanced against the potential benefit to all PDFBox users through
better test coverage.
> As I said before, the committers have final say, not I. If this gets added,
> then when we upgrade to that version of PDFBox, we will simply have to go
> through the necessary bureaucratic hoops.
Note that PDFBox 1.7 will in any case have a lot of new code and
dependencies thanks to the recent integration of the preflight and
xmpbox components.
Anyway, if you want to avoid the extra test dependency, I suggest you
look at the patch Rey's planning to submit and then submit a followup
patch that modifies the new test cases to not require the mock
library. That's the Apache way of resolving conflicts like these.
BR,
Jukka Zitting
RE: Mocking Frameworks
Posted by "Martinez, Mel - 1004 - MITLL" <m....@ll.mit.edu>.
Jukka - It isn't about what I 'want' to go through.
MIT license compatibility is irrelevant to this concern.
As I said before, the committers have final say, not I. If this gets added,
then when we upgrade to that version of PDFBox, we will simply have to go
through the necessary bureaucratic hoops. My only position is that that is
indeed actual work and I'm not convinced the benefit is sufficient to
justify it.
-Mel
-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
Sent: Friday, September 09, 2011 3:28 AM
To: dev@pdfbox.apache.org
Subject: Re: Mocking Frameworks
Hi,
On Fri, Sep 9, 2011 at 2:37 AM, rey malahay <re...@gmail.com> wrote:
> I appreciate the fact that this issue is still under discussion. In the
> meantime, I will put my work, which I intended to submit to the project,
on
> the backburners.
Please feel free to go ahead with your patch. Just add the mock
library as a dependency with test scope in the relevant POM file.
If Mel wants to go through legal hoops that are way beyond what normal
downstream users of PDFBox need, then IMHO it's up to him to do the
extra work. And we're not even talking about any troublesome licenses
here; MIT is perfectly compatible with all Apache licensing
requirements.
BR,
Jukka Zitting
Re: Mocking Frameworks
Posted by rey malahay <re...@gmail.com>.
Thanks Guys,
I will do as advised, and submit my patch once I get all my tests to pass.
Kind regards,
Rey Malahay
On 9 September 2011 01:28, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Fri, Sep 9, 2011 at 2:37 AM, rey malahay <re...@gmail.com> wrote:
> > I appreciate the fact that this issue is still under discussion. In the
> > meantime, I will put my work, which I intended to submit to the project,
> on
> > the backburners.
>
> Please feel free to go ahead with your patch. Just add the mock
> library as a dependency with test scope in the relevant POM file.
>
> If Mel wants to go through legal hoops that are way beyond what normal
> downstream users of PDFBox need, then IMHO it's up to him to do the
> extra work. And we're not even talking about any troublesome licenses
> here; MIT is perfectly compatible with all Apache licensing
> requirements.
>
> BR,
>
> Jukka Zitting
>
--
My heroes are the ones who survived doing it wrong, who made mistakes, but
recovered from them. - Bono
Re: Mocking Frameworks
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Sep 9, 2011 at 2:37 AM, rey malahay <re...@gmail.com> wrote:
> I appreciate the fact that this issue is still under discussion. In the
> meantime, I will put my work, which I intended to submit to the project, on
> the backburners.
Please feel free to go ahead with your patch. Just add the mock
library as a dependency with test scope in the relevant POM file.
If Mel wants to go through legal hoops that are way beyond what normal
downstream users of PDFBox need, then IMHO it's up to him to do the
extra work. And we're not even talking about any troublesome licenses
here; MIT is perfectly compatible with all Apache licensing
requirements.
BR,
Jukka Zitting
Re: Mocking Frameworks
Posted by rey malahay <re...@gmail.com>.
Thanks Guys,
I appreciate the fact that this issue is still under discussion. In the
meantime, I will put my work, which I intended to submit to the project, on
the backburners. I refuse to submit work that has not been properly unit
tested. I hope for an outcome in favour of a mocking framework which
developers will use in conjunction with their unit tests.
Kind regards,
Rey Malahay
On 8 September 2011 18:30, Adam Nichols <mr...@gmail.com> wrote:
> If there's a way to make it "excluded by default" when building a
> release version of the jar, then that should alleviate my concerns of
> adding another dependency. I'm not at all familiar with Maven, so I'm
> not sure how optional dependencies are handled. I believe
> bouncycastle is handled this way. I searched the Internet downloaded
> all the jar files manually until it compiled when I was first setting
> up the project. I know bc isn't required until runtime, but I haven't
> really looked into why and how all that works.
>
> Better (automated) testing makes it much easier to track down bugs,
> and I fully support that. Whenever I fix a bug, I try to include a
> sample PDF and write a JUnit test case demonstrates the fix actually
> does fix the issue. I mainly do this to prove to myself that my patch
> is fixing the issue I believe it is, but it also allows anyone else to
> run the test before the patch and after, plus it may head off some
> regression bugs down the road.
>
> Just my 2c. I'll wait for implementation specifics before I vote up or
> down.
>
> --Adam
>
> On Thu, Sep 8, 2011 at 8:05 PM, rey malahay <re...@gmail.com> wrote:
> > Hi Mel,
> >
> > So is the problem about maintaining the third party source? Gaining
> access
> > to the source for Mockito, or to any open source mocking framework should
> > not be a problem.
> >
> > Please advise.
> >
> > Thanks in advance,
> > Rey Malahay
> >
> >
> >
> > On 8 September 2011 08:44, Martinez, Mel - 1004 - MITLL <
> > m.martinez@ll.mit.edu> wrote:
> >
> >> On your point - if it is a requirement to be able to build and test the
> >> library from source, then, no, the problems of inclusion can persist.
> >>
> >> As part of our mission we archive all source for all 3rd party
> components
> >> and have to show the ability to build and support such. All artifacts
> >> required for the build have to be traceable and approved If the test
> >> harness requires some new artifact then that will have to be approved.
> >>
> >> Mel
> >>
> >> -----Original Message-----
> >> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> >> Sent: Thursday, September 08, 2011 3:31 AM
> >> To: dev@pdfbox.apache.org
> >> Subject: Re: Mocking Frameworks
> >>
> >> Hi,
> >>
> >> On Wed, Sep 7, 2011 at 4:13 PM, Martinez, Mel - 1004 - MITLL
> >> <m....@ll.mit.edu> wrote:
> >> > The interests Adam alluded to extend beyond just the direct interests
> of
> >> the
> >> > ASF. Adding any new third party code or package is often a very, very
> >> big
> >> > deal for those of us who depend on ASF components such as PDFBox.
> >>
> >> Note that a testing tool is by definition not included in the jar
> >> artifacts used downstream, so their licensing impact is minimal. The
> >> only problem is if the license of the testing tool would virally
> >> affect the license of the test code within PDFBox, but that won't be
> >> the case at least with the MIT-licensed Mockito.
> >>
> >> > However the disadvantages of including yet-another-package in the
> >> > distribution outweigh the benefits, imho.
> >>
> >> I disagree based on the above point. Better testing tools help improve
> >> quality and their impact on licensing is minimal.
> >>
> >> So, FWIW, +1 to using a mock tool in unit tests.
> >>
> >> BR,
> >>
> >> Jukka Zitting
> >>
> >
> >
> >
> > --
> > My heroes are the ones who survived doing it wrong, who made mistakes,
> but
> > recovered from them. - Bono
> >
>
--
My heroes are the ones who survived doing it wrong, who made mistakes, but
recovered from them. - Bono
Re: Mocking Frameworks
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Sep 9, 2011 at 2:30 AM, Adam Nichols <mr...@gmail.com> wrote:
> If there's a way to make it "excluded by default" when building a
> release version of the jar, then that should alleviate my concerns of
> adding another dependency. I'm not at all familiar with Maven, so I'm
> not sure how optional dependencies are handled.
This is a test dependency we're talking about, so it would never end
up in a release jar. Just like we don't have JUnit included in the
PDFBox jar.
BR,
Jukka Zitting
Re: Mocking Frameworks
Posted by Adam Nichols <mr...@gmail.com>.
If there's a way to make it "excluded by default" when building a
release version of the jar, then that should alleviate my concerns of
adding another dependency. I'm not at all familiar with Maven, so I'm
not sure how optional dependencies are handled. I believe
bouncycastle is handled this way. I searched the Internet downloaded
all the jar files manually until it compiled when I was first setting
up the project. I know bc isn't required until runtime, but I haven't
really looked into why and how all that works.
Better (automated) testing makes it much easier to track down bugs,
and I fully support that. Whenever I fix a bug, I try to include a
sample PDF and write a JUnit test case demonstrates the fix actually
does fix the issue. I mainly do this to prove to myself that my patch
is fixing the issue I believe it is, but it also allows anyone else to
run the test before the patch and after, plus it may head off some
regression bugs down the road.
Just my 2c. I'll wait for implementation specifics before I vote up or down.
--Adam
On Thu, Sep 8, 2011 at 8:05 PM, rey malahay <re...@gmail.com> wrote:
> Hi Mel,
>
> So is the problem about maintaining the third party source? Gaining access
> to the source for Mockito, or to any open source mocking framework should
> not be a problem.
>
> Please advise.
>
> Thanks in advance,
> Rey Malahay
>
>
>
> On 8 September 2011 08:44, Martinez, Mel - 1004 - MITLL <
> m.martinez@ll.mit.edu> wrote:
>
>> On your point - if it is a requirement to be able to build and test the
>> library from source, then, no, the problems of inclusion can persist.
>>
>> As part of our mission we archive all source for all 3rd party components
>> and have to show the ability to build and support such. All artifacts
>> required for the build have to be traceable and approved If the test
>> harness requires some new artifact then that will have to be approved.
>>
>> Mel
>>
>> -----Original Message-----
>> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
>> Sent: Thursday, September 08, 2011 3:31 AM
>> To: dev@pdfbox.apache.org
>> Subject: Re: Mocking Frameworks
>>
>> Hi,
>>
>> On Wed, Sep 7, 2011 at 4:13 PM, Martinez, Mel - 1004 - MITLL
>> <m....@ll.mit.edu> wrote:
>> > The interests Adam alluded to extend beyond just the direct interests of
>> the
>> > ASF. Adding any new third party code or package is often a very, very
>> big
>> > deal for those of us who depend on ASF components such as PDFBox.
>>
>> Note that a testing tool is by definition not included in the jar
>> artifacts used downstream, so their licensing impact is minimal. The
>> only problem is if the license of the testing tool would virally
>> affect the license of the test code within PDFBox, but that won't be
>> the case at least with the MIT-licensed Mockito.
>>
>> > However the disadvantages of including yet-another-package in the
>> > distribution outweigh the benefits, imho.
>>
>> I disagree based on the above point. Better testing tools help improve
>> quality and their impact on licensing is minimal.
>>
>> So, FWIW, +1 to using a mock tool in unit tests.
>>
>> BR,
>>
>> Jukka Zitting
>>
>
>
>
> --
> My heroes are the ones who survived doing it wrong, who made mistakes, but
> recovered from them. - Bono
>
Re: Mocking Frameworks
Posted by rey malahay <re...@gmail.com>.
Hi Mel,
So is the problem about maintaining the third party source? Gaining access
to the source for Mockito, or to any open source mocking framework should
not be a problem.
Please advise.
Thanks in advance,
Rey Malahay
On 8 September 2011 08:44, Martinez, Mel - 1004 - MITLL <
m.martinez@ll.mit.edu> wrote:
> On your point - if it is a requirement to be able to build and test the
> library from source, then, no, the problems of inclusion can persist.
>
> As part of our mission we archive all source for all 3rd party components
> and have to show the ability to build and support such. All artifacts
> required for the build have to be traceable and approved If the test
> harness requires some new artifact then that will have to be approved.
>
> Mel
>
> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: Thursday, September 08, 2011 3:31 AM
> To: dev@pdfbox.apache.org
> Subject: Re: Mocking Frameworks
>
> Hi,
>
> On Wed, Sep 7, 2011 at 4:13 PM, Martinez, Mel - 1004 - MITLL
> <m....@ll.mit.edu> wrote:
> > The interests Adam alluded to extend beyond just the direct interests of
> the
> > ASF. Adding any new third party code or package is often a very, very
> big
> > deal for those of us who depend on ASF components such as PDFBox.
>
> Note that a testing tool is by definition not included in the jar
> artifacts used downstream, so their licensing impact is minimal. The
> only problem is if the license of the testing tool would virally
> affect the license of the test code within PDFBox, but that won't be
> the case at least with the MIT-licensed Mockito.
>
> > However the disadvantages of including yet-another-package in the
> > distribution outweigh the benefits, imho.
>
> I disagree based on the above point. Better testing tools help improve
> quality and their impact on licensing is minimal.
>
> So, FWIW, +1 to using a mock tool in unit tests.
>
> BR,
>
> Jukka Zitting
>
--
My heroes are the ones who survived doing it wrong, who made mistakes, but
recovered from them. - Bono
RE: Mocking Frameworks
Posted by "Martinez, Mel - 1004 - MITLL" <m....@ll.mit.edu>.
On your point - if it is a requirement to be able to build and test the
library from source, then, no, the problems of inclusion can persist.
As part of our mission we archive all source for all 3rd party components
and have to show the ability to build and support such. All artifacts
required for the build have to be traceable and approved If the test
harness requires some new artifact then that will have to be approved.
Mel
-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
Sent: Thursday, September 08, 2011 3:31 AM
To: dev@pdfbox.apache.org
Subject: Re: Mocking Frameworks
Hi,
On Wed, Sep 7, 2011 at 4:13 PM, Martinez, Mel - 1004 - MITLL
<m....@ll.mit.edu> wrote:
> The interests Adam alluded to extend beyond just the direct interests of
the
> ASF. Adding any new third party code or package is often a very, very big
> deal for those of us who depend on ASF components such as PDFBox.
Note that a testing tool is by definition not included in the jar
artifacts used downstream, so their licensing impact is minimal. The
only problem is if the license of the testing tool would virally
affect the license of the test code within PDFBox, but that won't be
the case at least with the MIT-licensed Mockito.
> However the disadvantages of including yet-another-package in the
> distribution outweigh the benefits, imho.
I disagree based on the above point. Better testing tools help improve
quality and their impact on licensing is minimal.
So, FWIW, +1 to using a mock tool in unit tests.
BR,
Jukka Zitting
Re: Mocking Frameworks
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Am 08.09.2011 09:31, schrieb Jukka Zitting:
> Hi,
>
> On Wed, Sep 7, 2011 at 4:13 PM, Martinez, Mel - 1004 - MITLL
> <m....@ll.mit.edu> wrote:
>> The interests Adam alluded to extend beyond just the direct interests of the
>> ASF. Adding any new third party code or package is often a very, very big
>> deal for those of us who depend on ASF components such as PDFBox.
>
> Note that a testing tool is by definition not included in the jar
> artifacts used downstream, so their licensing impact is minimal. The
> only problem is if the license of the testing tool would virally
> affect the license of the test code within PDFBox, but that won't be
> the case at least with the MIT-licensed Mockito.
>
>> However the disadvantages of including yet-another-package in the
>> distribution outweigh the benefits, imho.
>
> I disagree based on the above point. Better testing tools help improve
> quality and their impact on licensing is minimal.
>
> So, FWIW, +1 to using a mock tool in unit tests.
Sorry for jumping in that late. I fully agree with Jukka. I'm not an expert on
mock tools but I guess we will need something like that to implement the more
complex test cases.
+1
> BR,
>
> Jukka Zitting
BR
Andreas Lehmkühler
Re: Mocking Frameworks
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Sep 7, 2011 at 4:13 PM, Martinez, Mel - 1004 - MITLL
<m....@ll.mit.edu> wrote:
> The interests Adam alluded to extend beyond just the direct interests of the
> ASF. Adding any new third party code or package is often a very, very big
> deal for those of us who depend on ASF components such as PDFBox.
Note that a testing tool is by definition not included in the jar
artifacts used downstream, so their licensing impact is minimal. The
only problem is if the license of the testing tool would virally
affect the license of the test code within PDFBox, but that won't be
the case at least with the MIT-licensed Mockito.
> However the disadvantages of including yet-another-package in the
> distribution outweigh the benefits, imho.
I disagree based on the above point. Better testing tools help improve
quality and their impact on licensing is minimal.
So, FWIW, +1 to using a mock tool in unit tests.
BR,
Jukka Zitting
RE: Mocking Frameworks
Posted by "Martinez, Mel - 1004 - MITLL" <m....@ll.mit.edu>.
Just a couple of quick comments.
-----Original Message-----
From: rey malahay [mailto:reymalahay@gmail.com]
>
> If it is a question of writing quality/ better code, then adding another
> library that supports the quality objective should not be a big deal. The
> last time I checked, the Apache Software Foundation was all about
> meritocracy. I believe that I am just doing my bit to uphold that value.
The interests Adam alluded to extend beyond just the direct interests of the
ASF. Adding any new third party code or package is often a very, very big
deal for those of us who depend on ASF components such as PDFBox. It
creates work in order to pass testing and accreditation and to do all
necessary paperwork. If something costs work then the benefit needs to be
at least proportional to the cost.
There are many good reasons to enable use of mock objects/doppelgangers for
unit testing so I don't want to imply that I don't advocate for that.
However the disadvantages of including yet-another-package in the
distribution outweigh the benefits, imho. Good design patterns can enable
mock testing without a framework (and of course, poor designs can preclude
it even with a framework).
The committers have final say, but I vote -1 on adding a mocking framework
to the PDFBox testing harness.
Re: Mocking Frameworks
Posted by rey malahay <re...@gmail.com>.
Hi Adam,
Thanks for the response. My answers to your questions below.
On 6 September 2011 21:13, Adam Nichols <mr...@gmail.com> wrote:
> As far as I know, PDFBox only uses JUnit to keep the dependencies at a
> minimum. Adding another library is a big deal, as it often causes
> people to jump through many hoops at their company (tests, audits,
> reconsidering alternatives, ripping out unnecessary dependencies so it
> will work on Android and other devices with limited resources, etc.).
>
If it is a question of writing quality/ better code, then adding another
library that supports the quality objective should not be a big deal. The
last time I checked, the Apache Software Foundation was all about
meritocracy. I believe that I am just doing my bit to uphold that value.
>
> Is there a specific reason you aren't just using JUnit to for the
> automated testing?
Mocking allows a developer to focus solely on the method under test, without
having to deal with dependencies, like method calls to perform tasks that
the method under test depends upon. This article illustrates the point very
well: http://bit.ly/plFpQy
> JUnit can accept any Java code in the tests, so it
> should be possible to ensure that objects interact with each other as
> expected without any problem.
>
If you have objects, i.e. instances of classes, interacting with each other
in a test, then that is no longer a *unit test*. What you have then is
an *integration
test*. At this point in time, my primary concern is that the code that I
submit to the PDFBox project has been *unit tested*. I want to be sure that
the code that I write behaves as expected, especially if there is a
likelihood that someone else adds to it, or makes changes to it...
So please let me know.
Thanks in advance,
Rey Malahay
>
> On Tue, Sep 6, 2011 at 10:18 PM, rey malahay <re...@gmail.com> wrote:
> > Hi Guys,
> >
> > I am currently rounding off my work for submission. Please could you
> advise
> > me on what mocking framework is being used in conjunction with the unit
> > tests for PDFBox? I am currently using Mockito. Is this acceptable?
> >
> > Please advise.
> >
> > Thanks in advance,
> > Rey Malahay
> >
> > ---------- Forwarded message ----------
> > From: rey malahay <re...@gmail.com>
> > Date: 3 September 2011 15:02
> > Subject: Mocking Frameworks
> > To: dev@pdfbox.apache.org
> >
> >
> > Dear PDFBox Team,
> >
> > May I use a mocking framework in my unit tests? I am currently using
> Mockito
> > in conjunction with JUnit, to write my unit tests and mock classes that
> do
> > not form part of the test objective. If so, how do we include the
> framework
> > in question with our patch submission?
> >
> > Please advise.
> >
> > Thanks in advance,
> > Rey Malahay
> >
> > --
> > My heroes are the ones who survived doing it wrong, who made mistakes,
> but
> > recovered from them. - Bono
> >
> >
> >
> > --
> > My heroes are the ones who survived doing it wrong, who made mistakes,
> but
> > recovered from them. - Bono
> >
>
--
My heroes are the ones who survived doing it wrong, who made mistakes, but
recovered from them. - Bono
Re: Mocking Frameworks
Posted by Adam Nichols <mr...@gmail.com>.
As far as I know, PDFBox only uses JUnit to keep the dependencies at a
minimum. Adding another library is a big deal, as it often causes
people to jump through many hoops at their company (tests, audits,
reconsidering alternatives, ripping out unnecessary dependencies so it
will work on Android and other devices with limited resources, etc.).
Is there a specific reason you aren't just using JUnit to for the
automated testing? JUnit can accept any Java code in the tests, so it
should be possible to ensure that objects interact with each other as
expected without any problem.
On Tue, Sep 6, 2011 at 10:18 PM, rey malahay <re...@gmail.com> wrote:
> Hi Guys,
>
> I am currently rounding off my work for submission. Please could you advise
> me on what mocking framework is being used in conjunction with the unit
> tests for PDFBox? I am currently using Mockito. Is this acceptable?
>
> Please advise.
>
> Thanks in advance,
> Rey Malahay
>
> ---------- Forwarded message ----------
> From: rey malahay <re...@gmail.com>
> Date: 3 September 2011 15:02
> Subject: Mocking Frameworks
> To: dev@pdfbox.apache.org
>
>
> Dear PDFBox Team,
>
> May I use a mocking framework in my unit tests? I am currently using Mockito
> in conjunction with JUnit, to write my unit tests and mock classes that do
> not form part of the test objective. If so, how do we include the framework
> in question with our patch submission?
>
> Please advise.
>
> Thanks in advance,
> Rey Malahay
>
> --
> My heroes are the ones who survived doing it wrong, who made mistakes, but
> recovered from them. - Bono
>
>
>
> --
> My heroes are the ones who survived doing it wrong, who made mistakes, but
> recovered from them. - Bono
>
Fwd: Mocking Frameworks
Posted by rey malahay <re...@gmail.com>.
Hi Guys,
I am currently rounding off my work for submission. Please could you advise
me on what mocking framework is being used in conjunction with the unit
tests for PDFBox? I am currently using Mockito. Is this acceptable?
Please advise.
Thanks in advance,
Rey Malahay
---------- Forwarded message ----------
From: rey malahay <re...@gmail.com>
Date: 3 September 2011 15:02
Subject: Mocking Frameworks
To: dev@pdfbox.apache.org
Dear PDFBox Team,
May I use a mocking framework in my unit tests? I am currently using Mockito
in conjunction with JUnit, to write my unit tests and mock classes that do
not form part of the test objective. If so, how do we include the framework
in question with our patch submission?
Please advise.
Thanks in advance,
Rey Malahay
--
My heroes are the ones who survived doing it wrong, who made mistakes, but
recovered from them. - Bono
--
My heroes are the ones who survived doing it wrong, who made mistakes, but
recovered from them. - Bono