removing explicit references to solution classes methods and fields

[RedJocker]

trying to solve issue #16

Still not entirely happy about this, but at least it won't throw build failures with incomplete solutions.

One thing that annoys me is that I'm having to set the INSTANCE property to null manually on tests through reflection on the method closeRoom(). That means that it has to be required on description the existence of a class org.hyperskill.phrases.data.room.AppDatabase and that it contains an INSTANCE property of type RoomDatabase.

I'm not sure how this code behaves with incorrect implementations of singletons, but for a correct implementation like the one in reference solution it works to close the database and set it to null.

Another thing that is annoying me is that some tests methods are throwing a warning with SQLiteBusyException, but it does the job it is supposed to do anyway. The problem here is that users might get confused by that warning if that test is not passing.

[hatepoint]

I'm not sure how this code behaves with incorrect implementations of singletons, but for a correct implementation like the one in reference solution it works to close the database and set it to null.

We will probably get the answer for this question when the project will go to testing phase

That means that it has to be required on description the existence of a class org.hyperskill.phrases.data.room.AppDatabase and that it contains an INSTANCE property of type RoomDatabase.

I'll add that to project objectives

I couldn't Google the better way to do this, but both mine and yours test cases worked for my solution without additional changes, so this should be good to go

[RedJocker]

Yeah, the thing is that most people don't do black box testing like we have to do so they just use methods and classes from tested code. Also we are not really doing unit test, which is what most people do, our tests are more like integration test or system test. I don't know what is the best term actually. What I do know is that often we have to have our own solutions because the kind of test we do is different from the regular use case for most people. Like for example mocking is pretty common on test code, but we don't usually use it because we are trying as much we can to leave the implementation as open as possible and to do mocking you have to assume a lot of implementation specifics.