hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9361) Strictly define the expected behavior of filesystem APIs and write tests to verify compliance
Date Tue, 17 Jun 2014 00:29:04 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-9361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033241#comment-14033241

Steve Loughran commented on HADOOP-9361:

h3. Validating S3/Swift tests.

It's still hard for me to run the S3 / Swift tests since I'd have to get credentials, 
These tests cost ~$0 to run as they don't persist data; you can use your own private
logins. I'd recommend >1 swift provider (I use RAX US, RAX UK and HP Cloud for their different
auth, consistency and throttling). S3 has different consistency models for US-east (worst)
everywhere else. You need to create buckets in different places there.

h3. test groupings

Only big feedback I have, is there some way we could have a single parent test for each FS
that runs all its contracts? All the concrete TestFooBarContract classes are basically copy
paste, I'd like to get rid of them. It's also harder for poor me to run all the HDFS contract

-1 to any unified supertest, as it doesn't isolate things the way having tests per operation
does. You get to
implement the features you want, and don't do a test for a RootContract if you don't want
your root FS deleted,
Append if you don't do append. etc. You also get to debug something {{TestHDFSRenameContract}}

# We can do well known names like {{TestHDFSContract}}, I can see that I've already done this
the {{TestNativeS3*}} tests.
# There's Junit Categories[ http://junit.org/javadoc/4.11/org/junit/experimental/categories/Categories.html].
Maven [does now support this|http://stackoverflow.com/questions/3100924/how-to-run-junit-tests-by-category-in-maven]
FWIW, categorizing the Hadoop tests would be a good idea at some point in the future anyway
"fast, slow, scale"
# There's JUnit suites -but use them and you will end up with your tests running if the suite
test runs -and
again if run individually.

I'd go for the naming, if everyone is happy with that and come up with a good name for the
HDFS tests that don't class with other 
things. How about {{TestHDFSContract*}}?

h3. FSExceptionMessages
I picked them up from one file (HDFS?) and used there. 

h3. Everything else

I'll do those...

How about {{"rejects-seek-past-eof"}}? 

> Strictly define the expected behavior of filesystem APIs and write tests to verify compliance
> ---------------------------------------------------------------------------------------------
>                 Key: HADOOP-9361
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9361
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: fs, test
>    Affects Versions: 3.0.0, 2.4.0
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>         Attachments: HADOOP-9361-001.patch, HADOOP-9361-002.patch, HADOOP-9361-003.patch,
HADOOP-9361-004.patch, HADOOP-9361-005.patch, HADOOP-9361-006.patch, HADOOP-9361-007.patch,
HADOOP-9361-008.patch, HADOOP-9361-009.patch, HADOOP-9361-011.patch, HADOOP-9361-012.patch,
HADOOP-9361-013.patch, HADOOP-9361-014.patch, HADOOP-9361-015.patch, HADOOP-9361.awang-addendum.patch
> {{FileSystem}} and {{FileContract}} aren't tested rigorously enough -while HDFS gets
tested downstream, other filesystems, such as blobstore bindings, don't.
> The only tests that are common are those of {{FileSystemContractTestBase}}, which HADOOP-9258
shows is incomplete.
> I propose 
> # writing more tests which clarify expected behavior
> # testing operations in the interface being in their own JUnit4 test classes, instead
of one big test suite. 
> # Having each FS declare via a properties file what behaviors they offer, such as atomic-rename,
atomic-delete, umask, immediate-consistency -test methods can downgrade to skipped test cases
if a feature is missing.

This message was sent by Atlassian JIRA

View raw message