Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Java [игнор отключен] [закрыт для гостей] / Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает? / 16 сообщений из 16, страница 1 из 1
19.01.2012, 12:24:52
    #37621805
Жентос
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
Собственно, возник такой вопрос.
Есть ли какая-то специфика (в задачах, в подходах, еще в чем-либо)?

Мне что-то ничего, за исключением того, что интерфейсы объявляют определенную спецификацию класса, не приходит в голову. А как считаете вы?
...
Рейтинг: 0 / 0
19.01.2012, 12:43:14
    #37621867
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
Жентособъявляют определенную спецификацию класса
да.
Это просто контракт.
Цель какая _конечная_?
У MS есть tlb описатель интерфейсов, как у DSL к XML
...
Рейтинг: 0 / 0
19.01.2012, 12:45:32
    #37621880
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
Petro123DSL к XML
XSD XDR к XML
...
Рейтинг: 0 / 0
19.01.2012, 13:04:15
    #37621952
Жентос
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
Petro123Жентособъявляют определенную спецификацию класса
да.
Это просто контракт.
Цель какая _конечная_?
У MS есть tlb описатель интерфейсов, как у DSL к XML
Цель? Честно говоря, не знаю. Для меня интерфейс -- набор методов, реализованных (так или инчае) у определенного класса. Не больше. Если у интерфейса clickable есть метод click(), то у любого объекта, реализующего интерфейс этот метод тоже должен быть....

P.S. мне этот вопрос на самомтоятельную проработку на тренинге дали.... но вот кроме этого предположения у меня больше мыслей по существу не возникает..
...
Рейтинг: 0 / 0
19.01.2012, 13:05:09
    #37621956
Жентос
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
Жентосу любого объекта
Класса, конечно же
...
Рейтинг: 0 / 0
19.01.2012, 13:13:26
    #37621986
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
Жентосна тренинге дали
ok
сабж это:
- другая сторона медали от наследования в ООП
- помогает заткнуть дыры ЯП при отсутствии множественного наследования
- контракт на поведение класса или группы классов с данным интерфейсом
- фасад для скрытия внутренней кухни классов\модуля, а также для дешёвого рефакторинга (DirectX)
.......
-
....
...
Рейтинг: 0 / 0
19.01.2012, 13:16:53
    #37621997
Leonidv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
ЖентосЦель? Честно говоря, не знаю. Для меня интерфейс -- набор методов, реализованных (так или инчае) у определенного класса. Не больше. Если у интерфейса clickable есть метод click(), то у любого объекта, реализующего интерфейс этот метод тоже должен быть....

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

Например:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
class Service {
 boolean isTrue(boolean b) { // Бага в модуле, от которого зависим
  return !b
 }
}

class ServiceConsumer {
  Service service;

  int calculate(boolean b) {
    if (service.isTrue(b)) {
     return 1;
    } else {
    return 0;
   }
 }
}

class TestServiceConsumer {
  @Test
  public bad() { // плохой способ тестирования
    ServiceConsumer sc = new ServiceConsumer();
    sc.service = new Service();
   assertEquals(1, sc.calculate.isTrue(true)); // Будет ошибка, хотя тестируемый модуль правильный
  }

 @Test
 public good() {
   ServiceConsumer sc =new ServiceConsumer();
   Service mockService = mock(Service.class);
   mockService.when(sc.isTrue(true)).then(true)
   sc.service = mockService;
   assertEquals(1, sc.calculate.isTrue(true)); 
 }
}



Реально работу Service проверяет только второй тест good, тогда как первый может свалится при корректно написанном ServiceConsumer.

Тут еще у меня применяется инъекция зависимости. Без нее код был бы такой (специально усиливаю final' модификатором) и написать модульный было бы невозможно:
Код: java
1.
2.
3.
 class  ServiceConsumer {
   private final Service service = new Service();
 }
...
Рейтинг: 0 / 0
19.01.2012, 13:19:06
    #37622001
Leonidv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
Petro123- помогает заткнуть дыры ЯП при отсутствии множественного наследования
Это не дыры. Это идеологический подход.

Petro123- фасад для скрытия внутренней кухни классов\модуля, а также для дешёвого рефакторинга (DirectX)

Здесь можно обойтись без интерфейсов, одним классом. Сути фасада это не поменяет.
...
Рейтинг: 0 / 0
19.01.2012, 13:20:54
    #37622008
Озверин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
Leonidv,

авторsc.calculate.isTrue(true)?
...
Рейтинг: 0 / 0
19.01.2012, 13:23:34
    #37622016
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
LeonidvЭто не дыры. Это идеологический подход.

не принимай на себя лично и на жабу
...
Рейтинг: 0 / 0
19.01.2012, 13:27:01
    #37622034
Leonidv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
ОзверинLeonidv,

авторsc.calculate.isTrue(true)?

Упс. Читать как:

Код: java
1.
sc.calculate(true)
...
Рейтинг: 0 / 0
19.01.2012, 13:27:37
    #37622038
Озверин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
Leonidv,

я вот смортю тест, и не увидел там, в каком месте мы тестируем Service?
ServiceConsumer - > calculate(boolean) - да, тестируем. Но я не понял выгоды от использование конкретно тут интрфейса.
А в вашем примере ошибка будет.да..на этапе компиляции.
...
Рейтинг: 0 / 0
19.01.2012, 13:36:50
    #37622066
Leonidv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
ОзверинLeonidv,

я вот смортю тест, и не увидел там, в каком месте мы тестируем Service?

Нигде не тестируем. Тестируем ServiceConsumer (class TestServiceConsumer {).
Выгода в том, что проверка ServiceConsumer не зависит от корректности реализации Service.

ОзверинА в вашем примере ошибка будет.да..на этапе компиляции.
Важна идея, а не конкретный код.

Исправил еще пару логических ошибок, теперь вроде правильно.

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
interface Service {
  boolean isTrue(boolean b);
}

class ServiceImlp {
 boolean isTrue(boolean b) { // Бага в модуле, от которого зависим
  return !b
 }
}

class ServiceConsumer {
  Service service;

  int calculate(boolean b) {
    if (service.isTrue(b)) {
     return 1;
    } else {
    return 0;
   }
 }
}

class TestServiceConsumer {
  @Test
  public bad() { // плохой способ тестирования
    ServiceConsumer sc = new ServiceConsumer();
    sc.service = new ServiceImlp();
   assertEquals(1, sc.calculate(true)); // Будет ошибка, хотя тестируемый модуль правильный
  }

 @Test
 public good() {
   ServiceConsumer sc =new ServiceConsumer();
   Service mockService = mock(Service.class);
   mockService.when(mockService.isTrue(true)).then(true)
   sc.service = mockService;
   assertEquals(1, sc.calculate(true)); 
 }
}

// Без DI
class ServiceConsumer {
  ServiceImlp service = new ServiceImlp();
}



Вот так правильно.
...
Рейтинг: 0 / 0
19.01.2012, 13:38:27
    #37622072
Leonidv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
Блин.
Код: java
1.
ServiceImlp implements Service 

- забыл указать. Но вроде и так должно быть ясно.
...
Рейтинг: 0 / 0
19.01.2012, 13:47:37
    #37622102
Leonidv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
ЖентосP.S. мне этот вопрос на самомтоятельную проработку на тренинге дали.... но вот кроме этого предположения у меня больше мыслей по существу не возникает..
А что за тренинг?
...
Рейтинг: 0 / 0
19.01.2012, 13:49:58
    #37622112
Жентос
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает?
LeonidvЖентосP.S. мне этот вопрос на самомтоятельную проработку на тренинге дали.... но вот кроме этого предположения у меня больше мыслей по существу не возникает..
А что за тренинг?
внутренний... я junior test automation
...
Рейтинг: 0 / 0
Форумы / Java [игнор отключен] [закрыт для гостей] / Интерфейсы ООП. Специфика применения в Test Automatio... Кто что думает? / 16 сообщений из 16, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]