Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Using powermock-api-mockito in tests?

Copy link to this message
Re: Using powermock-api-mockito in tests?
Thank you. Sometimes I get lost in the microscopic. Now I understand.

On Fri, Mar 22, 2013 at 6:48 PM, Dave Marion <[EMAIL PROTECTED]> wrote:
> David,
>   I was not trying to prevent you from being productive, I was trying to
> prevent you from wasting your time. I stated several times that
> MiniDFSCluster does not work on Windows. I'll try to be more specific.
>  After you mock the bash execution, you will likely find that you have
> broken the test for everyone else because MiniDFSCluster expects a certain
> directory permission, see [1] and [2] for lengthy discussions on the topic.
> In addition, when you get to the point of starting MiniDFSCluster, you will
> find that it does not work on Windows due to non-portable paths and such,
> see [3]. At that point you will be left with removing MiniDFSCluster and
> mocking every call to HDFS from the tests.
>   I think a better solution is to move the classloader tests that use
> AccumuloDFSBase to integration tests. These can be run on Hudson, which I
> think is using a *nix flavor of O/S and should run with no problem. Maybe a
> future version of MiniDFSCluster will work on Windows.
> [1] https://issues.apache.org/jira/browse/ACCUMULO-708
> [2]
> http://www.google.com/#hl=en&sclient=psy-ab&q=MiniDFSCluster+directory+permi
> ssions
> [3] http://www.google.com/#q=MiniDFSCluster+windows+paths&hl=en
> Dave
> -----Original Message-----
> From: David Medinets [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 22, 2013 5:43 PM
> Subject: Re: Using powermock-api-mockito in tests?
> How does it hurt the project if I spend time on this? Accumulo already
> compiles on Windows. It's the tests that are failing. How does skipping
> failing tests help? I suggest that unit tests should not spawn exec
> processes in any case because that is a source of slowness.
> Mocking the unix-specific stuff on Windows will lead to faster tests.
> On Fri, Mar 22, 2013 at 10:42 AM, Jim Klucar <[EMAIL PROTECTED]> wrote:
>> +1 to Dave's comment. I don't think we should be spending effort
>> +supporting
>> compiling on an unsupported runtime environment. If something fails
>> because it is too *nix-y then just skip that test with a local pom.xml
>> override or something.
>> On Fri, Mar 22, 2013 at 10:11 AM, Keith Turner <[EMAIL PROTECTED]> wrote:
>>> On Thu, Mar 21, 2013 at 10:16 PM,  <[EMAIL PROTECTED]> wrote:
>>> >
>>> > So we are getting into an area where you want to compile the
>>> > software on
>>> a platform that is not supported. If you want to compile on an
>>> unsupported platform, then I would suggest just ignoring the tests
>>> that won't work on that system.
>>> My thought on this is that if changes to make it work on windows
>>> improve the test and/or build process, then thats good.  On the other
>>> hand I would be opposed to making test and/or build more complex
>>> inorder to support windows.   I would define increasing complexity as
>>> making it more difficult to run, maintain, or improve the test and/or
>>> build process.
>>> >
>>> > I don't think that this needs to be changed now as Hadoop only
>>> > supports
>>> *nix based systems and we are close to a 1.5.0 release. If you want
>>> to tackle this in 1.6 (trunk) thats a different story.
>>> >
>>> >
>>> > ----- Original Message -----
>>> > From: "David Medinets" <[EMAIL PROTECTED]>
>>> > Sent: Thursday, March 21, 2013 10:08:48 PM
>>> > Subject: Re: Using powermock-api-mockito in tests?
>>> >
>>> > I hate ignoring things. It makes me uneasy. I'm looking at the
>>> > other tests as well. For example, the AccumuloDFSBase class depends
>>> > on running /bin/sh to find a umask. No reason that dependency can't
>>> > be mocked out during testing... If nothing else, this research will
>>> > form my own set of Accumulo Zen Koans.
>>> >
>>> > On Thu, Mar 21, 2013 at 10:03 PM, <[EMAIL PROTECTED]> wrote:
>>> >>
>>> >> Take a look at my other email on this subject, it might be better