java.util.Date is supported
or will i need a custom serializer
Later Jackson versions apparently dont need this
Thank you for your help @cacoco
The Scala Module supports serialization and limited deserialization of Scala Case Classes, Sequences, Maps, Tuples, Options, and Enumerations.
is there an Oauth2 filter implementation available somewhere?
@deenar we don’t have an OAuth2 Filter anywhere though I believe there is a finagle-oauth2 project here: https://github.com/finagle/finagle-oauth2 which should work. For your first question, if you want to content-negotiation like this you have several choices. Most simply is to switch on the accept header — we have a utility that may help here: https://github.com/twitter/finatra/blob/develop/http/src/main/scala/com/twitter/finatra/http/request/RequestUtils.scala#L31
Hi All, I wanted to write some test on Finatra Request parsing and Response writing for some of the application classes we have, but am stuck. I saw com.twitter.finatra.http.tests.marshalling.MessageBodyManagerTest, but it only seems to test overwritten read and write behaviour not the default one.
Do you have example of what you’re trying to do or what you’re running into?
''' test("Test PaymentRuleTest writer ") {
val testCase = ParseRules.getSampleTestCase()
val writerResponse = defaultMessageBodyWriter.write(testCase.inputMessage)
writerResponse.contentType should equal(MediaType.JsonUtf8)
mapper.parsePaymentRuleTest should equal(testCase)
}'''
val testCase = ParseRules.getSampleTestCase()
val writerResponse = defaultMessageBodyWriter.write(testCase.inputMessage)
writerResponse.contentType should equal(MediaType.JsonUtf8)
mapper.parsePaymentRuleTest should equal(testCase)
}'''
something along the lines of given a case class wanted to assert it's JSON encoding on the way out is as expected and a given JSON request is mapped correctly on the way in
you would issue a request to the server and expect the returned JSON is as expected
see: https://github.com/twitter/finatra/blob/develop/http/src/test/scala/com/twitter/finatra/http/EmbeddedHttpServer.scala#L127 and an example:
https://github.com/twitter/finatra/blob/develop/http/src/test/scala/com/twitter/finatra/http/tests/integration/doeverything/test/DoEverythingServerFeatureTest.scala#L243
https://github.com/twitter/finatra/blob/develop/http/src/test/scala/com/twitter/finatra/http/tests/integration/doeverything/test/DoEverythingServerFeatureTest.scala#L243
for what you’re describing: "something along the lines of given a case class wanted to assert it's JSON encoding on the way out is as expected and a given JSON request is mapped correctly on the way in”, yes a FeatureTest
I mean you are free to test the message body writer directly…if you really want to but you’re just testing our machinery and not your logic (and you should assume we test our machinery)
test what mechanism
testing serialization an deserialization of a case class is effectively writing tests of the framework which is again, great, but ultimately useless for testing anything related to your logic.
ok
If you just want to test json mapping, then yeah you can follow what happens in the Jackson tests:
https://github.com/twitter/finatra/blob/develop/jackson/src/test/scala/com/twitter/finatra/jackson/ScalaObjectMapperTest.scala
Or if you want to test how object mapping interacts with HTTP requests, then you can build a minimal injector like in the MessageBodyManagerTest (https://github.com/twitter/finatra/blob/develop/http/src/test/scala/com/twitter/finatra/http/tests/marshalling/MessageBodyManagerTest.scala#L72) and get references to the DefaultMessageBodyReader and DefaultMessageBodyWriter (which are supersets of logic and end up deferring to the ScalaObjectMapper for JSON serialization): https://github.com/twitter/finatra/blob/develop/http/src/main/scala/com/twitter/finatra/http/internal/marshalling/DefaultMessageBodyWriterImpl.scala#L68
But I’m not sure that tells you anything about your code built on top of this.
that it, this is what I was after, I can test all kinds of expected inputs quicker
the feature test covers the logic, but is expensive to do the same for fields which are just pass through
thanks
@deenar I wanted to add that I was not speaking only about FeatureTests earlier (there are several types of testing concepts that we espouse in Finatra: https://twitter.github.io/finatra/user-guide/testing/index.html#types-of-tests). If a use case is “expensive” to add into your tests it is possible that your system isn’t modularized well enough to allow easy testing of various components. Yes, you can always add some simple unit tests of the direct features provided by the framework (as mentioned before) especially if you’re trying to use them as regression tests against your specific data (in this case you want to always know that your case classes can be serialized/deserialized as they are perhaps unique) — but I would argue these are somewhat secondary tests and should not replace testing your higher-level logic on top of the framework of which, there are several ways to do so. Hope that helps. Thanks.