LINUX.ORG.RU

Принцип ООП, говори что делать, а не спрашивай.

 


0

1

Хочу спросить, может, кто решил эту проблему.

Есть класс в который я что-либо могу добавить и затем изменить.

Как мне написать на это тест (то что действительно изменилось), не получая вновь элемента для сравнения с новым?

class Some {
  ....

  public void edit(int id, String data) {
    // тут я забыл реализацию, или она корявая
  }

  ....
};

void testCaseSomeShouldBeEdit() {
  Some some = new Some();
  some.add(1, "data1");
  some.edit(1, "data2");

  // не хочу делать так:
  assertEquals(some.getData(1), "data2");

  // но надо как-то проверить
  // в клиентском коде я никогда не буду просить данные
}
★★★

Последнее исправление: pozitiffcat (всего исправлений: 2)

не получая вновь элемента

какого элемента? ничего не понятно... пока что держи, никакого элемента:

class A(object): pass
A.m = classmethod(lambda s: None)

print 'm' in dir(A)

t184256 ★★★★★
()
Ответ на: комментарий от t184256
class Some {
  ....

  public void edit(int id, String data) {
    // тут я забыл реализацию, или она корявая
  }

  ....
};

void testCaseSomeShouldBeEdit() {
  Some some = new Some();
  some.add(1, "data1");
  some.edit(1, "data2");

  // не хочу делать так:
  assertEquals(some.getData(1), "data2");

  // но надо как-то проверить
  // в клиентском коде я никогда не буду просить данные
}
pozitiffcat ★★★
() автор топика
Последнее исправление: pozitiffcat (всего исправлений: 1)

действительно изменилось), не получая вновь элемента для сравнения с новым?

А что изменилось то ты хоть сам сказать можешь?

Deleted
()
Ответ на: комментарий от pozitiffcat
// не хочу делать так:
assertEquals(some.getData(1), "data2");

обоснуй, че уж. если getData — полноценная часть интерфейса Some, то я не вижу причин, почему ее тут не задействовать в этом интеграционном тесте. если getData там не предусмотрен, то тестируй через ту часть интерфейса, которая есть. если такой нет, то edit и add не нужны.

поди тебя пойми...

t184256 ★★★★★
()

// не хочу делать так

А почему ты не хочешь так делать?

true_admin ★★★★★
()
Ответ на: комментарий от goingUp

На данный момент я так и делаю, использую Mocking. Я хочу услышать: правильно ли я делаю? Все ли так делают?

pozitiffcat ★★★
() автор топика
Ответ на: комментарий от pozitiffcat

Использование моков обычная практика. Тестироваться должен тот код, что реально работает, добавление дополнительных методов только для теста - плохо.

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

Заморочил я вас. Хотел именно это услышать, спасибо.

pozitiffcat ★★★
() автор топика
Ответ на: комментарий от goingUp

подобные методы (потыкать внутренее состояние) также могут помочь в отладке и что еще занятнее, при автодиагностике ПО, потому иногда их стоит оставлять как приватное api

Deleted
()
Ответ на: комментарий от pozitiffcat

если тестируешь Some то нет, если код его использующий то - да.

Deleted
()
Ответ на: комментарий от Deleted

подобные методы (потыкать внутренее состояние) также могут помочь в отладке и что еще занятнее, при автодиагностике ПО, потому иногда их стоит оставлять как приватное api

Может, если объект большой и сложный. Но часто можно обойтись без этого, так как это привязывает к деталям внутренней реализации. Если у ОП класс Some только собирает значения и передает их в некий storage то вполне можно потестировать и через мок.

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от goingUp

Может, если объект большой и сложный

Больших и сложных надо избегать а не костылять их

Но часто можно обойтись без этого, так как это привязывает к деталям внутренней реализации

Омг, какие детали реализации если речь о приватном api да еще и для диагностики?

Deleted
()
Ответ на: комментарий от Deleted

Больших и сложных надо избегать а не костылять их

Я тоже так считаю

Омг, какие детали реализации если речь о приватном api да еще и для диагностики?

Что за приватное api? Это ты так называешь методы типа как у ОП some.getData(1), который он не хотел делать? Можно например по разному хранить этот массив. Можно туда заносить все данные, а можно и только те, что будут использоваться для storage.

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

Что за приватное api? Это ты так называешь методы типа как у ОП some.getData(1), который он не хотел делать? Можно например по разному хранить этот массив. Можно туда заносить все данные, а можно и только те, что будут использоваться для storage.

Ты сейчас занимаешься гаданием на бреде ОП, без конкретики это просто топтание клавы.

Deleted
()
Ответ на: комментарий от pozitiffcat

Бгг, вот типичный пример - паттерн строитель иммутабельной карты:

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/coll...

После постройки он проверяет на конфликты, и если будет одинаковый ключ то выдаст ошибку, метода позволяющего проверить есть ли в этом билдере такой ключ - нет, но возможность его создать - есть.

Другой вариант - поточный writer xml, там в памяти ничего не хранится, и добавить возможность - есть, а получить - нет. Но зато у него внутри должна быть state machine которая меняется при добавлении нод и по ней уже можно контролировать что там было добавлено.

Вот тебе два примера который подпадают под твой «кейс» но кардинально отличаются.

Deleted
()

Мутабельные ООП петушки ITT.

anonymous
()
Ответ на: комментарий от pozitiffcat

Я хочу услышать: правильно ли я делаю? Все ли так делают?

Почему мнение других людей настолько важно для тебя? Сомневаешься в себе? Хочешь поддержки со стороны, чтобы обмануться и мысленно снять с себя ответственность?

loz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.