[
https://issues.apache.org/jira/browse/HDDS-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856857#comment-16856857
]
Eric Yang commented on HDDS-1554:
---------------------------------
[~elek] {quote}It works.{quote}
Yeah, if the user knows where to look. Robot plugin shows the link on the
navigation of the build, which is a much nicer way to access the html report
than digging into aggregated artifact link to find the log file.
{quote}I think we can agree that junit and a cli have exactly the same chance
to access the internal state of a remote backend in the running
container.{quote}
This is only true if cli is always wrapping on top of Java programs. If native
program like curl is used to access a web port. The end result will contain
the shorten stack trace of the server side because server responds to "Accept:
text/html" header from curl. The server buffered writer will try to flatten
the server side stack trace and render as html. If developer wants to preserve
the full stack trace of the client side and server side, then calling junit
test can capture more details because jersey client or rpc client does not ask
server to render result in html. Hence, full stack trace can be captured. For
example, HDDS-1583 was filed against Ozone RPC client because junit test was
able to capture the client exception that when server is offline. Robot
framework smoketest should have caught this, but didn't. Robot framework is a
general dispatcher framework like maven surefire plugin that checks for exit
code and stdin/stdout. It doesn't know the concept of Java exceptions, hence
writing white box tests in Java provides some advantages in exception handling
and collect more detailed stack trace.
My suggestion is to keep both. Robot framework testing is good for black box
tests where QA can think outside of the box. White box testing is good for
measuring if the components are built properly according to specification.
> Create disk tests for fault injection test
> ------------------------------------------
>
> Key: HDDS-1554
> URL: https://issues.apache.org/jira/browse/HDDS-1554
> Project: Hadoop Distributed Data Store
> Issue Type: Improvement
> Components: build
> Reporter: Eric Yang
> Assignee: Eric Yang
> Priority: Major
> Attachments: HDDS-1554.001.patch
>
>
> The current plan for fault injection disk tests are:
> # Scenario 1 - Read/Write test
> ## Run docker-compose to bring up a cluster
> ## Initialize scm and om
> ## Upload data to Ozone cluster
> ## Verify data is correct
> ## Shutdown cluster
> # Scenario 2 - Read/Only test
> ## Repeat Scenario 1
> ## Mount data disk as read only
> ## Try to write data to Ozone cluster
> ## Validate error message is correct
> ## Shutdown cluster
> # Scenario 3 - Corruption test
> ## Repeat Scenario 2
> ## Shutdown cluster
> ## Modify data disk data
> ## Restart cluster
> ## Validate error message for read from corrupted data
> ## Validate error message for write to corrupted volume
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
