На этом этапе мы будем не только решать вычислительные задачи, но и моделировать системы.
На лекции мы разобрали упрощённый пример того, как может выглядеть пост. Давайте посмотрим на более сложные примеры. Кстати, хорошая практика: анализировать системы, с которыми вы работаете в жизни, и продумывать, как бы сделали вы.
В качестве примера возьмём ВКонтакте: https://vk.com/dev/objects/post. Если страница недоступна, воспользуйтесь копией из каталога assets).
На что нужно обратить внимание В Kotlin используется camelCase для полей. Некоторые поля помечены как integer [0, 1], хотя по логике должны быть Boolean (у вас должны быть Boolean). Добавьте из перечисленных в документации около 10 полей простых типов (Int, String, Boolean). Поля типа object должны быть описаны отдельными классами (класс в Kotlin в документации VK называют object). Добавьте хотя бы одно такое поле (например, comments или likes). Для полей вы можете добавлять значения по умолчанию, аналогично параметрам функций. При таком подходе вам не нужно будет указывать значения всех аргументов при создании объектов класса. Что мы хотим получить:
Data-класс Post (и другие классы, которые могут быть вложены в Post). Объект WallService, который хранит посты в массиве.
Теперь нужно разобраться с функциональностью сервиса, отвечающего за стены пользователей: https://vk.com/dev/wall (копия).
Нас будут интересовать следующие методы:
создание записи; обновление записи. Создание записи Метод для создания записи должен выглядеть вот так:
fun add(post: Post): Post {
TODO()
}
Как он должен работать:
добавлять запись в массив, но при этом назначать посту уникальный среди всех постов идентификатор; возвращать пост с уже выставленным идентификатором. Подсказка Обновление записи Метод для обноления записи должен выглядеть так:
fun update(post: Post): Boolean {
TODO()
}
Как он должен работать:
находить среди всех постов запись с тем же id, что и у post и обновлять все свойства; если пост с таким id не найден, то ничего не происходит и возвращается false, в противном случае – возвращается true. Документация на Array
Следующая задача – написать автотесты на ваши методы:
на add – всего один, который проверяет, что после добавления поста id стал отличным от 0. на update – целых два: изменяем пост с существующим id, возвращается true; изменяем пост с несуществующим id, возвращается false. Пока мы не проверяем, что add действительно добавил, а update действительно что-то меняет.
Этим мы займёмся на следующих лекциях, когда достроим систему до действительно тестируемой.
По факту речь идёт о том, что нам придётся либо дописать специальные вспомогательные методы, либо научиться работать с nullable значениями.
Проблемы синглтонов Синглтоны создаются один раз при старте приложения и в единственном экземпляре.
Тестировать такое не всегда удобно: вы либо должны сделать метод, который «вычищает» синглтон, т.е. сбрасывает массив записей, либо переделать object на обычный класс.
Если вы сделаете обычный класс, тогда в каждом тесте вы можете поступить следующим образом. Пример для update:
class WallServiceTest { @Test fun updateExisting() { // создаём целевой сервис val service = WallService() // заполняем несколькими постами service.add(Post(/* заполняете поля /)) service.add(Post(/ заполняете поля /)) service.add(Post(/ заполняете поля /)) // создаём информацию об обновлении val update = Post(/ заполняете поля */)
// выполняем целевое действие
val result = service.update(update)
// проверяем результат (используйте assertTrue или assertFalse)
assertTrue(result)
}
} Если вы хотите оставить WallService в виде object, то можно добавить в него метод очистки clear:
object WallService { private var posts = emptyArray()
fun clear() {
posts = emptyArray()
// также здесь нужно сбросить счетчик для id постов, если он у вас используется
}
} А затем указать JUnit с помощью аннотации @Before, что метод необходимо вызывать перед каждым тестом:
class WallServiceTest {
@Before
fun clearBeforeTest() {
WallService.clear()
}
@Test
fun updateExisting() {
...
}
}