Restore java test code in samples

[jmini]

@cbornet :

The commit d9fe34a removed all the java samples test code

[jmini]

The real commit (the one included on the master branch) is c8c316e.

---

Git command to see what was modified with this commit:

git diff 5340c35ce123c18daa82f62131b3d1606bd1ceab..c8c316e41ee85a3ba1de4c39559eb8cf9a1690e4 --name-status

I will analyze the results.

[jmini]

I did some analysis and I propose to restore following files at commit c8c316e (see the list at the end of this message)

See my commit: jmini@ce671d8

Feedback is welcome.
@cbornet : have you other files in mind?

I will soon open a PR: issue247_restore-unit-test ->master.

---

• feign io.swagger.client.StringUtilTest

• jersey1 io.swagger.client.ApiClientTest

• jersey1 io.swagger.client.ConfigurationTest

• jersey1 io.swagger.client.StringUtilTest

• jersey1 io.swagger.client.auth.ApiKeyAuthTest

• jersey1 io.swagger.client.auth.HttpBasicAuthTest

• jersey1 io.swagger.client.model.EnumValueTest

• jersey2-java8 io.swagger.client.ApiClientTest

• jersey2-java8 io.swagger.client.ConfigurationTest

• jersey2-java8 io.swagger.client.JSONTest

• jersey2-java8 io.swagger.client.StringUtilTest

• jersey2-java8 io.swagger.client.auth.ApiKeyAuthTest

• jersey2-java8 io.swagger.client.auth.HttpBasicAuthTest

• jersey2 io.swagger.client.ApiClientTest

• jersey2 io.swagger.client.ConfigurationTest

• jersey2 io.swagger.client.JSONTest

• jersey2 io.swagger.client.StringUtilTest

• jersey2 io.swagger.client.auth.ApiKeyAuthTest

• jersey2 io.swagger.client.auth.HttpBasicAuthTest

• jersey2 io.swagger.client.model.EnumValueTest

• okhttp-gson io.swagger.client.ApiClientTest

• okhttp-gson io.swagger.client.ConfigurationTest

• okhttp-gson io.swagger.client.JSONTest

• okhttp-gson io.swagger.client.StringUtilTest

• okhttp-gson io.swagger.client.auth.ApiKeyAuthTest

• okhttp-gson io.swagger.client.auth.HttpBasicAuthTest

• okhttp-gson io.swagger.client.model.EnumValueTest

• resttemplate io.swagger.client.ApiClientTest

• resttemplate io.swagger.client.auth.ApiKeyAuthTest

• resttemplate io.swagger.client.auth.HttpBasicAuthTest

• resttemplate io.swagger.client.model.EnumValueTest

[cbornet]

There should also be tests for the petstore (PetApiTest, StoreApiTest, UserApiTest)

[jmini]

Ok I definitively need more background on this. The generated stuff is still there:

Before my commit:

• io.swagger.client.PetApiTest

Now the file still exists (introduced with e0b0248)

• org.openapitools.client.PetApiTest still present on master

The package names have changed, but this is documented: New default values for the generated code

---

What was lost during the process are the manual written Unit tests, that are added to the sample after code generation. I thought this issue is about restoring them.

---

Please continue the discussion. I am not sure I got everything right.

[cbornet]

The tests you see are the auto-generated tests. But for the samples we had true implementations of tests with actual assertions validating the responses. The scripts normally prevent overriding these files during generation. These tests allow to validate the generated code more deeply.

[cbornet]

See this diff for a part of the code that was removed.

[jmini]

First part: #346 (can be merged without waiting for the second part).

---

In an other PR I will restore the removed implementation that @cbornet would like to have.

[cbornet]

Did you progress on that ? We still don't have good CI tests on our Java clients...

[jmini]

I started it twice (there is a branch on my fork), but it requires some time to do it properly (to sort out what needs to be rested and what not).

The setup with the local host table (see this page) is also complicated for me (never took the time to do the setup locally)

I also wanted to run the petstore server directly (without docker), but nobody replied to the change proposed here OpenAPITools/openapi-petstore#6 (the ultimate goal is to build the petstore server and to deploy a released artifact on Maven Central - this way we can fetch it and start it on the JVM, no docker and port mapping involved)

---

I my opinion working on a solution as described in #689 would add more value than working on this (which does not imply that I will not solve this, both approaches are complementary)

[cbornet]

We should work on this issue...