[
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.
{quote}
It's still hard for me to run the S3 / Swift tests since I'd have to get
credentials,
{quote}
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) and
everywhere else. You need to create buckets in different places there.
h3. test groupings
{quote}
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 tests
{quote}
-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 for
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
(v6.2#6252)
