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