smoyer64 commented on issue #20: IDEA: Replace restfuse with Rest Assured based 
tests
URL: https://github.com/apache/directory-scimple/pull/20#issuecomment-411484545
 
 
   There has been little progress within the SCIM community towards creating an 
official TCK and I'd hoped we could eventually provide that.  I think that for 
those using SCIM with the Java programming language, running via the 
``maven-failsafe-plugin`` isn't an issue.  My thought behind making this a Java 
application (preferably some sort of shaded/uber JAR) was that it would be 
easier for the rest of the SCIM community to run (i.e. those using other 
languages).
   
   I know upREST is behind ... there's more on my laptop than what's on Github 
but I'm trying to figure out a good way to do authentication at the moment.  
There are some things that I like about the declarative nature of Restfuse that 
I was trying to carry forward.  What you've done with RestAssured looks pretty 
good (I'm not a fan of using it with Groovy) so perhaps it does make sense 
going forward.  We tend to use AssertJ rather than Hamcrest ... I don't 
remember whether there's already a dependency for that.
   
   I hadn't spent any real time thinking about the client compliance suite but 
why are you using Arquillion for the server compliance testing?  It could 
almost be a Postman configuration and really just needs a REST client that 
calls the server implementation.  If you're simply using Arquillion for CDI 
there's weld-junit5 which provides a nice CDI integration.  If you're starting 
up a server (the in-memory server?) to run tests against, I'd argue that that 
should be something run as a separate step.
   
   To convert to JUnit 5, there's a nice utility that our friend (and JavaOne 
co-conspirator) @boyarsky wrote that will do a lot of the conversion - 
https://github.com/boyarsky/convert-junit4-to-junit5.  Be aware that there is 
no concept for Runners in JUnit 5 so using the Arquillion runner won't work.
   
   I see there are a bunch of files outside the compliance modules included in 
this PR ... Can those be separated into other PRs?  Changing server-common has 
the potential to introduce breaking changes to the providers we've got in 
production.  We've been using the lack of failures in PSU implementations as 
part of the validation for those PRs.  Some day there should be enough tests in 
SCIMple itself to identify breaking changes!

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to