stage1 tests

[RedJocker]

by reading the description you gave I can see that you are thinking this stage as being more about the layout of 3 of your screens, main_screen, sign_up and log_in.

currently you are just testing the existence of the views that you are requiring to exist, but I think you can also add some assertions for the expected properties of these views. Like for example the buttons are expected to have some text, you should test that. EditText are expected to have some hint and some expect a particular inputType, you should test that. And so on...

To be sure that a certain View will always have that property it is better to put these assertions on the lazy init block. This is better because we should not assume the order in which JUnit run the @Test s and eduTools will only give feedback on the first failing @Test it sees, which may be bugged because it expected the view to have a property that was asserted on another @Test method later.

So for example you could have this

private val phoneField: EditText by lazy {
        val view = activity.findViewByString<EditText>("phoneNumber")

        val actualInputType = view.inputType
        val expectedInputType = InputType.TYPE_CLASS_PHONE
        assertTrue("The inputType for phoneNumber should be phone", expectedInputType == actualInputType)

        val actualHint = view.hint.toString().lowercase()
        val expectedHint = "phone"
        assertEquals("Wrong hint for phoneNumber", expectedHint, actualHint)

        view
    }

the first time you use phoneField it will run all the lazy init block including the assertions. The last statement of the init block is the return value, this value will be cached for every future use of the field. The init block only runs once, always on the first time. Junit will re-instantiate fields for every @Test so you don't have to worry about if another @Test has used that field or not

[BratinaRok]

Hi, I have made some improvements to the tests.

[RedJocker]

I did an general overview of the description and the tests and they seem to match on content. At some point we will need to make description improvements, but I'm not the guy for making good descriptions, that is after tests are created.

I think you can move to next stage. Ideally we want to be able to reuse previous stage into following stages, but some times it does not make sense, or just partially. To reuse previous stages tests you can simply have a copy of stage1 tests file together in stage2 folder and so on. But we don't want to have files with same name having different content between them. If you need a different version of stage1 tests you can choose to either create an alternative name like Stage1UnitTestB or cut some of the code to stage 2 tests. It depends on how much reuse.

You don't really need to wait me to move to other stages, I'm just commenting what I think from what I've seem. Also if you feel like working in more than one stage simultaneously or get back later to a stage you already did you can just do no problems.