Migrate (set_once) tests to Kotlin

[yevhenii-nadtochii]

This PR migrates recently added (set_once) tests to Kotlin.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 34.21%. Comparing base (96be3e1) to head (6b5f592).
Report is 5 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master     #144   +/-   ##
=========================================
  Coverage     34.21%   34.21%           
  Complexity      360      360           
=========================================
  Files           134      134           
  Lines          2709     2709           
  Branches        220      220           
=========================================
  Hits            927      927           
  Misses         1719     1719           
  Partials         63       63           

[yevhenii-nadtochii]

@armiol @alexander-yevsyukov PTAL

[alexander-yevsyukov]

Please see my comments.

[alexander-yevsyukov]

Why do we need an object here? Why cannot we have just top level functions?

[alexander-yevsyukov]

This applies not only to setonce. So if we want these functions, they should probably go as test fixtures at the very start level of project dependencies.

[alexander-yevsyukov]

Names of these functions are a bit long to be utilities. We also seem to have already things like assertValid() and assertInvalid(). Please have a look around.

[alexander-yevsyukov]

It is also useful to return a result of the executing the runnable. It helps when you need to verify the result of building a message. We also have tests that run .validate() in combination with just building a message.

Again, please have a look around the code of the project.

[alexander-yevsyukov]

I mean the code like this:

val msg = assertDoesNotThrow {
    protoSet {
        element.add(toAny("42"))
        element.add(toAny(42))
    }
}
msg.validate().shouldBeEmpty()

[alexander-yevsyukov]

If we introduce something like assertValid() it may be implemented as the code above. But, again, we need to return the produced message so that the tests that use the utility can do something useful with it without the "gymnastics" with var declarations.

[yevhenii-nadtochii]

I've introduced them within an object as (set_once)-specific intentionally.

1. Assertions within IsValid are not applicable as they rely on validation being done in builder() method. The test subject here throws right from a builder setter.
2. Within (set_once) tests, we don't need the results, so I don't return them, allowing the test cases be one-lines.

I didn't look at them as general-purpose. I can move them back to Spec* files (two files need them), and make private. Or we can discuss vocally.

[alexander-yevsyukov]

LGTM, assuming agreements we've made in the video call.