[
https://issues.apache.org/jira/browse/FINERACT-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102791#comment-17102791
]
Michael Vorburger commented on FINERACT-949:
--------------------------------------------
One particularly annoying issue seems to be that RestAssured, before
FINERACT-884, returns {{List<Map<String, Object>>}} if the JSON contains a
list, but just {{(LinkedHash)Map}} in case of API replies such as errors? This
makes it particularly painful to "nicely" write e.g. the {{StaffTest}}, which
expects a list in reply to {{/api/v1/staff}}, but for
{{testStaffListFetchWrongState()}} needs to assert the return of an error.
That's presumably why {{getStaffListWithState()}} was written to return an
{{java.lang.Object}} ...
... in https://github.com/apache/fineract/pull/842/files?w=1 I've made it
return a List, and fort he exceptional case of
{{testStaffListFetchWrongState()}} used {{@Test(expected =
ClassCastException.class)}}, but that seems more like a wrong hack... :D
There must be a better style? What I'm missing here is some sort of {{Any}}
with an {{asList()}} and an {{isError()}} and what not.
BTW while that {{Map<String, Object>}} I'm using is slightly better than what
we have, the Maps' {{Object}} value is still "ugly".
PS: In this context, I also explored using REST Assured's {{getObject()}} with
a {{TypeRef<>}} instead of {{get()}}, e.g. with this in {{Utils}}, but it turns
out this actually isn't required, and doesn't really help with the problem
described above.
{code:java}
public static <T> T performServerGetObject(final RequestSpecification
requestSpec, final ResponseSpecification responseSpec,
final String getURL, final String jsonAttributeToGetBack, final
TypeRef<T> typeRef) {
final String json =
given().spec(requestSpec).expect().spec(responseSpec).log().ifError().when().get(getURL).andReturn().asString();
if (jsonAttributeToGetBack == null) { return (T) json; }
return from(json).getObject(jsonAttributeToGetBack, typeRef);
{code}
> Improve Java API style used for writing integration tests in Fineract
> ---------------------------------------------------------------------
>
> Key: FINERACT-949
> URL: https://issues.apache.org/jira/browse/FINERACT-949
> Project: Apache Fineract
> Issue Type: Improvement
> Reporter: Michael Vorburger
> Priority: Major
> Labels: integration-test, technical, testing
>
> The current (Java) "style" that integration tests are written in in Fineract
> is... really ugly!
> They are from a bygone era when Java had no generic. All those weird
> {{java.util.HashSet}}, with a lot of {{java.lang.Object}} etc. in tests
> are... so not 21st century style.
> I don't really have the answer here, yet - but perhaps others have ideas -
> how does one write Java (test) code in 2020 which deals with JSON in a nicer
> way?
> Does REST Assured (http://rest-assured.io) meanwhile offer a better way to do
> this kind of thing?
> Could https://github.com/skyscreamer/JSONassert be of use and interest for
> this purpose?
> BTW if using REST Assured better than we are is part of the answer here, then
> let's first do FINERACT-884.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
