CVE - CVE-2018-2581 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2581

^ javafx reference about 152

@ron Sure 🙂

@mariofelesdossantosjr There is nothing really TornadoFX specific with database access, just create a controller which returns the data like you normally would, optionally calling

.observable()

on the collection of items to make it easier to bind the resulting list to tables etc.

@edvin https://github.com/ronsmits/mocktest

@edvin tbh I am not sure what sort of magic MockK does under the hood. I expect it's some reflection proxy magic. Spring Boot can also proxy concrete classes with AOP so I am not surprised it's possible. @ron’s example is on point.

@poohbar I know several ways to proxy a class, but the point here is that you want to change functionality in these classes. I don't quite see how that's possible.

With interfaces, you just create a new class that adheres to the interface and implement whatever makes sense for the test in the functions exposed by the interface

Proxying a class doesn't let you change the

behavior, unless you use interceptors and all sorts of nastyness

yup, well when you have a proxy the proxy calls the real class right? all you have to is call your test implementation instead.

That approach won't let you change field values though

Yeah, I don't think you need to change field values because you are treating the mocked class as a black box.

but checkout mine or Ron's example I think it makes it pretty clear

OK, will look at it as soon as I have time

My first idea when I started looking at this was to be able to manipulate the component map in FX. Create the mock object the way I did and then insert that into the FX.components

@poohbar when I do a println(controller::class.toString) it reports it as controller not as a proxy objec

@poohbar changing fields can happen in a controller you could for example have a state set (db connected, authenticated) in kotlin you dont often make functions for that

um.. so let's say the state is "dbconnected = true", when the controller is a mock you dont actually have to store the state. You just mock the function

isConnected()

to return

true

whenever you want it to return that.

but in kotlin you usually do not make the isConnected function

you would just do controller.dbconnected = true

yeah, you can mock properties with MockK too

they are implemented by a method under the hood, so it's similar to mocking

isConnected()

under the hood

Well let's see what @edvin comes up with

I seem to have no internet connection at home today, so I don't know if I'll be able to look at this today

Get your 1200 baud modem out of storage?

@ron Sure, Slack would load in about 4.5 hours 🙂

ROFL

Back when I can!