[unit testing] HtmlRenderer error cases

[Matt Ryan <os...@mvryan.org>]

Hi,

As I'm in the process of adding unit tests for HtmlRenderer, I'm wondering
about some cases that could arguably be error conditions.

For example, if I have an HtmlRenderer instance and I call the "link()"
method with an empty string passed in as the info parameter, the method
will faithfully generate an anchor tag that is not wrapped around any
text.  Likewise, if I call the "link()" method with an empty string passed
in as the url parameter, it will also generate an anchor tag with an empty
string value for the href.

Do we prefer to make these methods accept as many inputs as possible, or
would we like to make use of e.g. IllegalArgumentException to indicate when
the method is being invoked in a way that doesn't make sense?

I just want to know the general feeling, so I can consistently enforce it
via the unit tests I'm writing.


-MR

Re: [unit testing] HtmlRenderer error cases

[Bertrand Delacretaz <bd...@apache.org>]

Hi Matt,

On Sat, Feb 4, 2017 at 12:29 AM, Matt Ryan <os...@mvryan.org> wrote:
> As I'm in the process of adding unit tests for HtmlRenderer, I'm wondering
> about some cases that could arguably be error conditions.

That's org.apache.sling.junit.impl.servlet.HtmlRenderer, right?

> ...Do we prefer to make these methods accept as many inputs as possible, or
> would we like to make use of e.g. IllegalArgumentException to indicate when
> the method is being invoked in a way that doesn't make sense?...

Considering that the renderer is used during the execution of tests,
I'd say the priority is to avoid blocking tests and avoid creating
HTML that's not accepted by typical client browsers. Ugly or
suboptimal HTML doesn't really matter.

So my preference is to make those methods very lenient in what they
accept, and have them do their best to produce output that allows the
main purpose of the whole thing, which is running tests, to be
fulfilled.

-Bertrand