Comments 7
Про тесты-объекты не очень понятно? Вы предлагаете создавать объект на каждой тестируемой фичи?
Тогда объект будет состоять по сути из одного метода исполняющего тест… Идея выглядит не очень разумной. Объекты достаточно дорогостоящая структура. Или я что-то не понял?..
за статью, спасибо… Весьма познавательно…
Тогда объект будет состоять по сути из одного метода исполняющего тест… Идея выглядит не очень разумной. Объекты достаточно дорогостоящая структура. Или я что-то не понял?..
за статью, спасибо… Весьма познавательно…
Про тесты-объекты не очень понятно? Вы предлагаете создавать объект на каждой тестируемой фичи?
Тогда объект будет состоять по сути из одного метода исполняющего тест… Идея выглядит не очень разумной. Объекты достаточно дорогостоящая структура. Или я что-то не понял?..
Именно это я и предлагаю.
В чем заключается «дорогостоимость» объекта? В очередной раз отмечу: я ведь не с проста Smalltalk беру в примеры, а там (почти) все — объекты.
Примеров, где объект имеет «по сути» один метод, можно набрать много: например, блок (замыкание)… или нить… Вообще, это признак хорошего объектного дизайна: один объект — одна ответственность.
… А если не «по сути», то у теста довольно много даже базовых обязанностей, кроме простого выполнения: хранить имя, связи с другими тестами, какие-нибудь комментарии, историю выполнения и много другой метаинформации. С тестами, лежащими как методы где-то в недрах класса, довольно сложно что-либо сделать в плане управления — это закрывает множество возможностей по развитию средств управления тестами и их более широкому использованию на различных этапах разработки ПО. Или, например, воспроизвести историю разработки — целая проблема. А насколько это было бы удобно в плане обучения других и самого себя?
В общем, есть целый ряд задумок, связанных с TDD/BDD и дальнейшим развитием существующих принципов разработки с использованием тестов, где тесты-объекты очень нужны.
В чем заключается «дорогостоимость» объекта? В очередной раз отмечу: я ведь не с проста Smalltalk беру в примеры, а там (почти) все — объекты.
Ну, если про Smalltalk говорить, то тесты-методы вполне себе объекты. Чем они вас не устраивают? )
Мне понятна ваша идея. Но в ней есть внутренняя системная проблема… Тесты должны быть простыми до самоочевидности, иначе рано или поздно возникнет ситуация, когда придется тестировать тесты. И в конечном счете всё сведется к ситуации когда Тесты делаются ради тестов…
А это основной аргумент тех, кто не испытывает пиетета TDD. Сам не раз наблюдал когда народ по полдня бодается с проблемами в очередной версии rspec'а вместо того, чтобы писать приложение. Последняя проблема с rspec'ами в Engines отняла конкретно несколько дней…
Я уже честно говоря надоело подтрунивать над своими коллегами… Но у них аргумент… Rspec — требование заказчика… Хотя казалось бы какая разница заказчику?!
«Бодание» с проблемами используемой/-ого библиотеки/фреймворка вместо написания приложения — проблема, относящаяся к любому используемому в проекте стороннему (да и не только стороннему) коду. За все, в том числе и удобство, приходится платить. В данном случае за более развитые средства управления тестами, возможно, придется заплатить большей сложностью фреймворка.
Но не факт, на самом деле, что возникнут какие-то дополнительны сложности: более естественные вещи как раз обычно получаются более простыми. Представлять тест с помощью соответствующего объекта может (должно, на мой взгляд — насколько я успел это дело продумать) оказаться как раз более удачным решением, снимающим целый ряд проблем и ограничений. Именно поэтому мне и не очень нравится текущее решение: тест должен в себе содержать реализующий его код, а не наоборот. В конечном итоге, это просто вопрос хранения кода тестов: можно хранить их и в методах, как сейчас, а можно и отдельно. …А на простоте написания тестов это никак не скажется.
Но не факт, на самом деле, что возникнут какие-то дополнительны сложности: более естественные вещи как раз обычно получаются более простыми. Представлять тест с помощью соответствующего объекта может (должно, на мой взгляд — насколько я успел это дело продумать) оказаться как раз более удачным решением, снимающим целый ряд проблем и ограничений. Именно поэтому мне и не очень нравится текущее решение: тест должен в себе содержать реализующий его код, а не наоборот. В конечном итоге, это просто вопрос хранения кода тестов: можно хранить их и в методах, как сейчас, а можно и отдельно. …А на простоте написания тестов это никак не скажется.
В конечном итоге, это просто вопрос хранения кода тестов: можно хранить их и в методах, как сейчас, а можно и отдельно. …
В смысле, «отдельно»? 0_о Код метода является частью объекта. И он в этом смысле хранится в самом объекте. В объектах, помимо методов, коду больше негде храниться…
Вы предлагаете для каждого метода сделать свой отдельный объект. Собственно в RSpec'е, если я не ошибаюсь, так и есть. И проблема с Rspec'ом в RoR-приложениях, в частности в том, что запуск прогона в крупных проектах отнимает довольно немало времени.
Ему, прежде чем начать тестирование, приходится проинициализировать все объекты, неговоря уже о том, что перед этим надо проинициализировать среду исполнения, то бишь приложение. И это порой может занимать десятки минут…
Это я и имел ввиду, когда говорил, что объекты — дорогостоящая структура.
Или я вас опять не понял…
В смысле, «отдельно»? 0_о Код метода является частью объекта. И он в этом смысле хранится в самом объекте. В объектах, помимо методов, коду больше негде храниться…
Самое простое:
Test newOn: [true should be: false].
Test class >> newOn: aBlockClosure
^ self new code: aBlockClosure
Test >> code: aBlockClosure
code := aBlockClosureВы предлагаете для каждого метода сделать свой отдельный объект. Собственно в RSpec'е, если я не ошибаюсь, так и есть. И проблема с Rspec'ом в RoR-приложениях, в частности в том, что запуск прогона в крупных проектах отнимает довольно немало времени.
Ему, прежде чем начать тестирование, приходится проинициализировать все объекты, неговоря уже о том, что перед этим надо проинициализировать среду исполнения, то бишь приложение. И это порой может занимать десятки минут…
Это я и имел ввиду, когда говорил, что объекты — дорогостоящая структура.
Едва ли задержки вызваны самим фактом хранения тестов в отдельных объектах (если это действительно так реализовано в RSpec). По крайней мере, я не могу навскидку нафантазировать каких-либо возможных причин для этого. В крупных проектах и на стандартном xUnit прогон тестов отнимает немало времени — там тоже нужно проинициализировать все объекты и среду. Возможно, в RSpec время тратится на что-то еще, может быть, в тестах используется DSL, который транслируется в момент выполнения? Если у вас есть конкретная информация об эффекте — будет интересно узнать.
Скажу по секрету, что Display в Eclipse перекочевал из VisualAge Smalltalk. Впрочем, как и SWT — это порт CommonWidgets/CommonGraphics из того же VisualAge Smalltalk.
Sign up to leave a comment.
Откуда есть пошел xUnit