Здравствуйте, novitk, Вы писали:
N>Здравствуйте, LaPerouse, Вы писали: LP>>Ты делаешь умозаключение "RCP — плохо, OSGi — RCP, следовательно OSGi — плохо". Я тебе указал на ошибку. N>Где я сделал такое умозаключение?
C>Работает. Хотя весь этот OSGI — полная туфта.
Ну тут я, как ты знаешь, согласен. Только мне вагон кода достался на Eclipse RCP...
Итак, ты думаешь, что OSGi — "туфта", видимо, исходя из своего опыта работы с RCP, иначе на кой черт ты это сюда приплел?
N>К реализации OSGi в equinox у меня претензий нет, есть претензии к стандарту.
Какие претензии?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Итак, ты думаешь, что OSGi — "туфта", видимо, исходя из своего опыта работы с RCP, иначе на кой черт ты это сюда приплел?
Очевидно, что OSGI мне не люб, но мне достался продукт которые его использует.
N>>К реализации OSGi в equinox у меня претензий нет, есть претензии к стандарту. LP>Какие претензии?
Мы кажется уже общались на эту тему, не вижу смысла повторються.
Здравствуйте, xBlackCat, Вы писали:
BC>С PHP у Идеи всё пучком — смотри "побочный" проект — PHPStorm. Всё, что есть в нём — автоматически есть в Idea Ultimate.
BC>С флексом, насколько мне известно, у Идеи тоже хорошо — умеет всё, кроме GUI Degisner'а.
Ну GUI и даром не нужно, да и php не так критичен, а вот с flex типа лучше стало, да только с Flex SDK 4.Х
Придётся сначала обновлять и только потом щупать
Может кто-нить "пощупал", стоит оно того?
Здравствуйте, LaPerouse.
LP> Нет, вредно. Не всякую функциональность целесообразно тестировать юнит-тестами.
Пример, чтобы не быть голословным.
Если это либа — значит публичный метод должен быть покрыт тестом — значит он используется (из тестов)
Если это приложение — значит публичный метод не используется — значит не нужен и может быть удалён.
Здравствуйте, xBlackCat, Вы писали:
BC>Здравствуйте, LaPerouse.
LP>> Нет, вредно. Не всякую функциональность целесообразно тестировать юнит-тестами. BC>Пример, чтобы не быть голословным.
1. Любая функциональность с широкой недетерминированностью — например, такая, как действие пользователя (пользовательские интерфейсы).
2. Функциональность, которая и так уже проверяется опосредовано (в составе другой функциональности). Оверхед от 100-процентного покрытия слишком велик, поэтому нужно искать разумный компромисс. Это очевидно любому, кто применял юнит-тестирование на практике.
BC>Если это либа — значит публичный метод должен быть покрыт тестом — значит он используется (из тестов) BC>Если это приложение — значит публичный метод не используется — значит не нужен и может быть удалён.
Разделение на приложения и либы весьма условное. Собственно, при грамотном проектировании оно отсутствует вообще. Приложение состоит из модулей, которые взаймодействуют друг с другом через публичные сервисы, и разницы между компонентой-библиотекой и компонентной-не-библиотекой нет вообще. Каждая компонента может разрабатываться независимыми коллективами, которые не знают про другие компоненты. Так что подсвечивать все неиспользуемые публичные методы — маразм. Но если это легко отключается, то еще нормально, и разговор на эту тему можно закрыть.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse.
Вы писали:
LP> Здравствуйте, xBlackCat, Вы писали: LP> BC>Здравствуйте, LaPerouse. LP> LP>> Нет, вредно. Не всякую функциональность целесообразно тестировать юнит-тестами. LP> BC>Пример, чтобы не быть голословным. LP> 1. Любая функциональность с широкой недетерминированностью — например, такая, как действие пользователя (пользовательские интерфейсы).
Как это связано с методом класса?
LP> 2. Функциональность, которая и так уже проверяется опосредовано (в составе другой функциональности). Оверхед от 100-процентного покрытия слишком велик, поэтому нужно искать разумный компромисс. Это очевидно любому, кто применял юнит-тестирование на практике.
Мысль понятна, но кадется, притянуто за уши к данной теме
LP> BC>Если это либа — значит публичный метод должен быть покрыт тестом — значит он используется (из тестов) LP> BC>Если это приложение — значит публичный метод не используется — значит не нужен и может быть удалён. LP> Разделение на приложения и либы весьма условное. Собственно, при грамотном проектировании оно отсутствует вообще. Приложение состоит из модулей, которые взаймодействуют друг с другом через публичные сервисы, и разницы между компонентой-библиотекой и компонентной-не-библиотекой нет вообще. Каждая компонента может разрабатываться независимыми коллективами, которые не знают про другие компоненты.
Вот здесь, кто разрабатывает компоненты, просто обязан проверить всевозможные входные данные. Опять, следовательно есть тест — мотод публичный используется.
Я бы побоялся использовать неоттестированную компоненту. LP> Так что подсвечивать все неиспользуемые публичные методы — маразм. Но если это легко отключается, то еще нормально, и разговор на эту тему можно закрыть.
Это отключается легко, что уже было ранее сказанно.
Здравствуйте, neFormal, Вы писали:
C>>Да, и весь код должен быть покрыт тестами, так что unused-методов не должно быть. В идеале. F>это какая то наркомания.. F>зачем покрывать на 100% ?.
Чтоб проверить
Здравствуйте, xBlackCat, Вы писали:
BC>Здравствуйте, LaPerouse. BC>Вы писали:
LP>> Здравствуйте, xBlackCat, Вы писали: LP>> BC>Здравствуйте, LaPerouse. LP>> LP>> Нет, вредно. Не всякую функциональность целесообразно тестировать юнит-тестами. LP>> BC>Пример, чтобы не быть голословным. LP>> 1. Любая функциональность с широкой недетерминированностью — например, такая, как действие пользователя (пользовательские интерфейсы). BC>Как это связано с методом класса?
Например, есть у нас публичный метод createExporterWindow. Протестируй его.
LP>> 2. Функциональность, которая и так уже проверяется опосредовано (в составе другой функциональности). Оверхед от 100-процентного покрытия слишком велик, поэтому нужно искать разумный компромисс. Это очевидно любому, кто применял юнит-тестирование на практике. BC>Мысль понятна, но кадется, притянуто за уши к данной теме
Не притянута, ведь это все публичные методы, которые не вызываются, а значит будут подсвечены IDE. И таких случаев не так уж и мало (посмотри хотя бы сколько методов addXXXListener в любом проекте).
LP>> BC>Если это либа — значит публичный метод должен быть покрыт тестом — значит он используется (из тестов) LP>> BC>Если это приложение — значит публичный метод не используется — значит не нужен и может быть удалён. LP>> Разделение на приложения и либы весьма условное. Собственно, при грамотном проектировании оно отсутствует вообще. Приложение состоит из модулей, которые взаймодействуют друг с другом через публичные сервисы, и разницы между компонентой-библиотекой и компонентной-не-библиотекой нет вообще. Каждая компонента может разрабатываться независимыми коллективами, которые не знают про другие компоненты. BC>Вот здесь, кто разрабатывает компоненты, просто обязан проверить всевозможные входные данные. Опять, следовательно есть тест — мотод публичный используется. BC>Я бы побоялся использовать неоттестированную компоненту.
Тогда этот случай сводится к предыдущему.
Тут кстати все проще будет. Я делаю так. Тесты лежат не с компонентой, а в проекте с сервисом, который компонента имплементирует, либо вообще отдельном проекте. А компонента для проверки правильности реализации сервиса просто вызывает эти тесты, подсовывая себя. То есть тесты — своеобразная спецификация для сервиса, которой разработчики компоненты должны удовлетворять.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Cyberax, Вы писали:
C>>>Да, и весь код должен быть покрыт тестами, так что unused-методов не должно быть. В идеале. F>>это какая то наркомания.. F>>зачем покрывать на 100% ?. C>Чтоб проверить
int GetId(){return id;} проверить?. ~_^
кроме того есть ещё приватные методы, которые тоже покрываете тестами?.
Здравствуйте, LaPerouse, Вы писали:
LP>Например, есть у нас публичный метод createExporterWindow. Протестируй его.
Легко. Вызывается метод и появившееся окно проверяется на функциональность с помощью java.awt.Robot.
LP>Не притянута, ведь это все публичные методы, которые не вызываются, а значит будут подсвечены IDE. И таких случаев не так уж и мало (посмотри хотя бы сколько методов addXXXListener в любом проекте).
Вынести общую логику листенеров в отдельный класс и тестировать её, а потом использовать. Конечно, идея тестировать прокси-методы кажется глупой идеей, но раз в год и палка стреляет — кто-то и этот метод может изменить.
LP>Тут кстати все проще будет. Я делаю так. Тесты лежат не с компонентой, а в проекте с сервисом, который компонента имплементирует, либо вообще отдельном проекте. А компонента для проверки правильности реализации сервиса просто вызывает эти тесты, подсовывая себя. То есть тесты — своеобразная спецификация для сервиса, которой разработчики компоненты должны удовлетворять.
+1
В этом и есть идея тестирования: тестировать мелкие детальки и потом только их взаимодействие.
Здравствуйте, neFormal, Вы писали:
F>>>зачем покрывать на 100% ?. C>>Чтоб проверить F>int GetId(){return id;} проверить?. ~_^
А оно где-то используется или просто для украшения?
F>кроме того есть ещё приватные методы, которые тоже покрываете тестами?.
Стараюсь.
Здравствуйте, Cyberax, Вы писали:
F>>int GetId(){return id;} проверить?. ~_^ C>А оно где-то используется или просто для украшения?
ну так ты же тесты пишешь не для того, чтобы успокоить IDEA, чтобы оно тебе не подсвечивало метод..
или я неправ?.
F>>кроме того есть ещё приватные методы, которые тоже покрываете тестами?. C>Стараюсь.
Здравствуйте, neFormal, Вы писали:
F>>>int GetId(){return id;} проверить?. ~_^ C>>А оно где-то используется или просто для украшения? F>ну так ты же тесты пишешь не для того, чтобы успокоить IDEA, чтобы оно тебе не подсвечивало метод.. F>или я неправ?.
У тебя этот метод просто так есть? Если просто так, то он не нужен. А если нужен, то он где-то используется и это "где-то" надо протестировать. Что вызовет автоматическое использование этого метода.
F>>>кроме того есть ещё приватные методы, которые тоже покрываете тестами?. C>>Стараюсь. F>а как это делаешь ты?.
Приватные методы кем-то вызываются. И этот "кто-то" должен быть в итоге публичным.
Здравствуйте, Cyberax, Вы писали:
F>>>>int GetId(){return id;} проверить?. ~_^ C>>>А оно где-то используется или просто для украшения? F>>ну так ты же тесты пишешь не для того, чтобы успокоить IDEA, чтобы оно тебе не подсвечивало метод.. F>>или я неправ?. C>У тебя этот метод просто так есть? Если просто так, то он не нужен. А если нужен, то он где-то используется и это "где-то" надо протестировать. Что вызовет автоматическое использование этого метода.
независимо от ide.. ты говоришь, что стараешься покрывать тестами 100% кода.. я спрашиваю, зачем ты покрываешь тестами тривиальные методы типа вышеуказанного?.
Здравствуйте, neFormal, Вы писали:
C>>У тебя этот метод просто так есть? Если просто так, то он не нужен. А если нужен, то он где-то используется и это "где-то" надо протестировать. Что вызовет автоматическое использование этого метода. F>независимо от ide.. ты говоришь, что стараешься покрывать тестами 100% кода.. я спрашиваю, зачем ты покрываешь тестами тривиальные методы типа вышеуказанного?.
Так я не пытаюсь покрыть примитивные методы. Они просто автоматически получаются покрытыми из-за того, что тестируется функциональность, использующая их.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, neFormal, Вы писали:
C>>>У тебя этот метод просто так есть? Если просто так, то он не нужен. А если нужен, то он где-то используется и это "где-то" надо протестировать. Что вызовет автоматическое использование этого метода. F>>независимо от ide.. ты говоришь, что стараешься покрывать тестами 100% кода.. я спрашиваю, зачем ты покрываешь тестами тривиальные методы типа вышеуказанного?. C>Так я не пытаюсь покрыть примитивные методы. Они просто автоматически получаются покрытыми из-за того, что тестируется функциональность, использующая их.
Это совсем разные вещи. Изначально таки речь шла именно о 100-ом покрытии кода, а потом кто-то решил плавно подменить тему )
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, xBlackCat, Вы писали:
BC>Здравствуйте, LaPerouse, Вы писали:
LP>>Например, есть у нас публичный метод createExporterWindow. Протестируй его. BC>Легко. Вызывается метод и появившееся окно проверяется на функциональность с помощью java.awt.Robot.
Это как раз такой случай, когда накладные расходы на тестирование превышают пользу. Я никогда не тестирую GUI. При правильном проектировании в GUI не происходит ничего сверхсложного, вся обработка происходит в сервисах приложения, к которым идет обращение из GUI, вот они должны быть покрыты тестами.
LP>>Не притянута, ведь это все публичные методы, которые не вызываются, а значит будут подсвечены IDE. И таких случаев не так уж и мало (посмотри хотя бы сколько методов addXXXListener в любом проекте). BC>Вынести общую логику листенеров в отдельный класс и тестировать её, а потом использовать. Конечно, идея тестировать прокси-методы кажется глупой идеей, но раз в год и палка стреляет — кто-то и этот метод может изменить.
Это опять такой случай, когда накладные расходы на тестирование превышают пользу.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
F>>>независимо от ide.. ты говоришь, что стараешься покрывать тестами 100% кода.. я спрашиваю, зачем ты покрываешь тестами тривиальные методы типа вышеуказанного?. C>>Так я не пытаюсь покрыть примитивные методы. Они просто автоматически получаются покрытыми из-за того, что тестируется функциональность, использующая их. LP>Это совсем разные вещи. Изначально таки речь шла именно о 100-ом покрытии кода, а потом кто-то решил плавно подменить тему )
Ничуть. 100%-е покрытие кода совсем не означает, что надо влоб все методы тестировать.
