Added test case for nullable enum that defaults to null and defaults …

[darmstrong1]

…to an enum value is not null.

Hi Kossi,

Thank you for looking at this issue so quick!
Your solution looks good.

I added one test case. I wanted to see if I could make it work for a nullable enum that defaults to null and defaults to a value in the enum if it is not null.
I had to create a data class with just the enum in it and give it the default value, then make that enum class the nullable field for it to work. I could not think of another way to do it since I can't give an enum two default values. Even if I could, I don't know how it would choose which to use.
I just wanted to see if it were possible because I'm sure cases will come up where the value can be null and if it is not, people will want the value to have a default for backward compatibility.

[kossi]

Ok thanks, I'll merge this to that PR.

Yeah sorry. I don't know if the structure should be with enum defaults a bit different. Example separate annotations for enum defaults or something like that. Or the schemata structure for field defaults and enum defaults are different but let's see

[kossi]

Sorry btw about the force-pushing stuff on my branch on your commit. Or removed one unused import that I had added earlier.

Reasoning for doing the force-push is that I thought commit history included the merge commit message. Well anyways it probably doesn't really matter or the PR just now two commits

[darmstrong1]

kossi, no problem.
I was thinking the same thing as you, that it may be better to have a separate enum for avro defaults since they have a different purpose from "regular" defaults.
I see thake created an issue to support enum defaults, so he seems to have the same idea.