Всем привет.
Есть описание объекта, реализации нет. Мой класс испольует этот объект. Как лучше его провалидировать, без создания фейкового класса, если известны функции объекта.

Подскажите, куда глянуть, что прочитать

вот же
http://1c.ru/club/

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

(1) не катит, причем по всем параметрам. Не можешь дать совет -- постой в сторонке, посмтори на умных дядь. Может, сам умнее станешь

(2) Они есть. Доступа к объекту не предвидится.
Мне дали интерфейс, я должен отдать код, который выполняет функцию от доступных объектов интерфейса....

Моя задача: знать, что мой код валиден. Объект -- 200 полей с геттерами/сеттерами. Я могу написать свой фейк, но, полагаю, что проблема не нова, и как это это можно решить средствами, например, jUnit

*от доступных объектов интерфейса....  -- от доступных методов, конечно же

Автор спросил какую-то НЕХ... И хочет ответа...

(5) ну, не со всем...

вот смотри, утебя в СВН есть интерфейс -- это договор о том, что есть у объекта.

как смоделировать этот объект с минимальными усилиями, если у тебя нет реализации?

и ты пишешь свой объект, который опирается на чужой объект, котоого нет в СВН, но есть интерфейс. Как ты можешь гарантирповать, что твой код работает.

У меня цель -- определить дефект объекта из СВН, а потом его заюзаь. С использованием определился, с валидацией проблемка

http://habrahabr.ru/post/146753/

(0)
Ну вот например я - вообще не понимаю - что ты пишешь.

"Есть описание объекта, реализации нет." - что такое описание? В стихах?

"Как лучше его провалидировать" - это что? Проверить отступы в коде?

" я должен отдать код, который выполняет функцию от доступных объектов интерфейса.... " - это вообще феерия. Но раз должен - отдай.

(9) описание -- интерфейс (interface)
провалидировать -- пингануть его методы на ОДЗ (область допустимых значений)

Мне надо создать класс, который работает с вот этим интерфейсом. Класс должен работать хорошо, но что мне на вход придет -- это я хз. И вот это я должен проверить

(8) Это все-таки не совсем то.
Может, я криво описал задачу. Мне надо симулировать присутствие объекта. У объекта 1000 геттеров. Я не хочу писать себе 1000 методов в код теста, чтобы проект скомпилировать. Мне нужно от силы 30 (это тоже много).

Интерфейс определен, мне нужна фабрика объектов по определенному интерфейсу, чтобы проверить свой код -- работает он или нет

(10)
Работает с этим интерфейсом - реализует его, или вызывает методы у некоего объекта реализующего этот интерфейс?

В (8) написано как перехватывать методы объектов.
Перехватываешь, и смотришь, что тебе приходит.
Если ты правильно прочитал статью - тебе не нужно писать сто методов. Тебе нужно написать один метод перехвата вызовов. В котором вызываемый метод в строковом виде ты можешь получить через context.getMethod()

(12) вызывает методы. Т.е. я не знаю реализации (мне это и не надо), я знаю интерфейс. И этот объект надо проверить. Как проверять я знаю, мне нужен "экземпляр объекта, похожий на настоящий". И чтобы не я его писал. Я, конечно, могу, но 1000 геттеров -- это печально

(13) там больше девелоперское решение, если я правильно понял. А мне нужно в плоскости юнит-теста. Мокирование ближе. А статья хорошая

автор, ты нашел, у кого спрашивать про яву... попробуй еще на форуме домохозяек

(15) Не, тут есть люди, в которых я верю. Вот, НС тот же -- умный чувак  :)

тебе наверное сюда http://javascript.ru/ нужно

(0) В чем проблема написать свою реализацию?

class blablaImpl implements blabla {
...
}

Не совсем понимаю чего вы хотите, но может рефлексия поможет?!

(13) Там в статье про EJB написано. Думаю что это не нужно ТС.

(18) У тебя есть 10000 свойств объекта. Им всем нужен геттер. Давай сыграем с тобой в игру....


В том то и дело, что фейковыую реализацию писать не охота и затратно. Как это обойти?

(20) Если у него столько свойств, то , скорее всего, он криво спроектирован. Это не нормально. Я вот не совсем понял что ты хочешь сделать в (11). Если ты хочешь сделать свой класс на основе интерфейса, но не хочешь реализовывать 1000 геттеров, то попробуй сделать класс обертку над этим объектом и проверь интересующие тебя 30 свойств. Пихаешь в эту обертку свой объект по интерфейсу и 30 методов связываешь с 30 методами интерфейса.

(21)я так и сделал... но это не совсем то, чтоя ищу

и 1000 -- это условность, она тут для того, чтобы понять, что что-то не так в моем подходе

(22) "Как лучше его провалидировать" - что ты имеешь ввиду?! Проверить на null? Или проверить на корректность объекта бизнес логики? Почему интерфейс сам не предоставляет такой метод (isValid())?

(24) я хочу проверить на валидность бизнес-логики. Это моя задача.


Я аписал код, его надо проверть. Но как я его роверю, если реализациив СВН нет? Отдавать плохой код -- не вариант

(25) Так смысл в том, чтобы не зная реализации программировать от интерфейса. Если есть понимание как должен работать объект(сделан нормальный джавадок ), то надо писать без реализации. Если нет доки и хочется протестировать, то я бы сделал так:
-Сделал бы фабрику, возращающую объекты интерфейса.
-Сделал бы свою реализацию интерфейса(адаптер). Реализовав только нужные мне методы, которые хочу проверить. Остальные оставил бы пустыми.
-По тестовому ключу возвращал бы из этой фабрики этот объект.

(26) это то, что надо.
а нет ли какой фигни, которая делает мокап по интерфейсу?

Грубо говоря. Мне надо написать юнит-тест объекта по интерфейсу. Естественно, тест должен работать. А как это проверить без реализации объекта -- хз

(0) Что такое мокап? А никак и не проверишь. Есть такой термин TDD - test driven development. Там смысл в том, что сперва пишешь тест, а потом уже реализаци.

wiki:Разработка_через_тестирование

(29) http://jmock.org/

(30) я тестер....

блин, мне нужно порлучить тонну объектов по интерфейсу, чтобы видеть, чт метод не упал

и как это вот сделать?

В общем, написал фековый Data Provider, который инициализировал свойств рандомными значения свойств. Криво, но что поделать

jMock и Mockito работают, но они инициализируют значениями по умлочанию, что для тестов плохо

jUnit Theory требуют доступа к конструктору, а о нем я ничего не знаю.

(26) Ну, вот так и сделал...