Компания Bredex объявила (http://www.bredex.de/en/news/first.html) о планах по открытию исходных текстов основных компонентов автоматизированной системы тестирования GUI-интерфейсов GUIDancer (http://www.bredex.de/en/guidancer/first.html) и передаче кода под опеку проекта Eclipse для последующего развития в рамках субпроекта Jubula (http://www.eclipse.org/proposals/jubula/).
В выпущенном компанией пресс-релизе (http://www.bredex.de/en/news/pdf/Jubula_en.pdf) управляющий директор Bredex и ведущий проекта GUIdancer Ахим Лорке (Achim Lörke) пишет, что данный шаг нацелен на то, чтобы предоставить клиентам уверенность в длительной работоспособности решения. Компания также отмечает, что сейчас в основном в автоматизированных системах тестирования делается упор на JUnit или тестирование API, упуская такую область как тестирование интерфейса ПО с позиции пользователя.
Согласно планам, Bredex планирует выпустить открытый проект Jubula (http://www.eclipse.org/proposals/jubula/) вес...URL: http://www.bredex.de/en/news/first.html
Новость: http://www.opennet.me/opennews/art.shtml?num=28826
> Плагины для проверки Swing, SWT, RCP, GEF и HTML приложений;Сделали бы еще для Qt, цены бы им не было. А то для него только платный Squish и без особых альтернатив. С другой стороны он очень хороший и стоит своих денег.
Трудоёмкость написания кода на языке C++ по некоторым оценкам примерно в 3-5 раз больше, чем на Java.
Тормознутость Java-приложений по некоторым оценкам примерно в 3-5 раз больше, чем приложений на C++.
Производительность труда машиниста экскаватора в 100 раз выше, чем производительность оператора совковой лопаты. Стоимость эксплуатации лопаты и экскаватора прямо пропорциональна их производительности. Пользуются и тем и другим.В чем спор?
В странах где труд человека стоит дорого - копают только экскаваторами. А там где труд не стоит ничего, особенно в армии РФ копают только солдатами.
> копают только экскаваторами.Да, подход жабистов-энтерпрайзников - это именно не разбираясь пригнать кучу рабочих и экскаватор, выставить заграждения, развесить знаки/предупреждения, етц. Хотя клиент хотел всего-то пару цветов на градку посадить вообще. А ему до кучи пару кубов грунта перелопатили, грязь развезли, и вообще, грядка метр на метр больше похожа на болото стала. После чего клиента пытаются убедить что это нормално и что все так делают, плати, дескать за вызов бригады. А потом еще и искренне удивляются когда клиент почему-то не хочет звать ту же бригаду копать вторую грядку.
Это всё от того, что "земля" не та. Нативная. А была бы та, то достаточно было бы счелчка пальцами, чтобы зацвела "грядка".Другими словами, в окружении железа, поддерживающего нативное исполнение байт-кода, такой ситуации в принципе бы не возникло. Вы, сишники, не испытываете никаких затруднений с непосредственным "общением" с железом, так как у вас выполняется фактически машкод.
> подход жабистов-энтерпрайзниковЕсли жабист-энтерпрайзник ничего кроме жаба-энтерпрайза не знает - то так оно и есть, клумбы экскаваторами не вскапывают.
> Тормознутость Java-приложений по некоторым оценкам примерно в 3-5 раз больше, чем приложений
> на C++.Да, если используется GCJ.
> Да, если используется GCJ.К сожалению GCJ способен поднять только приложения уровня "Hello World!".
Не только. На нём Eclipse запускается и какое-то время работает, отжирая ресурсы.
>Тормознутость Java-приложений по некоторым оценкам примерно в 3-5 раз больше, чем приложений на C++.Это абстракция. Бывает и на одном уровне - все зависит от конкретной задачи.
Плюс некоторые ошибки не возможно совершить ввиду ограничений языка и платформы.memory leak, разименование неинициализированного указателя, срыв стека, множественное наследование, переопределение операторов, подмена исполняемого кода.
Часть возможностей конечно осталась... и некоторым даже их хватает чтобы криво написать программу.
кто бы говорил про memory leak, когда потребление памяти в 50 выше
как java разработчик, уверяю.. memory leak никуда не делся ))
он лишь немного видоизменился... и всё... выглядит это совсем не так, как на c++ но результат тот же.. съедание всей доступной памяти...
> memory leak,Наглая ложь. В практически любом языке програмер может так или иначе назаводить те или иных сущности, потребляющие под себя память. И без явного указания програмером "мне больше не нужно больше вот это, убейте" - трудно определить когда больше никогда не потребуется некая сущность, так что ее уже можно убить и занять память используемую оной под что-то еще. Память у ява-программ течет так что дай боже. Чуть иначе чем у сишных, но это уже детали. А GC делает отлов этого факта сложнее на глаз - когда видно что прога жрет кучу памяти и жрач растет еще и фиг просто так поймешь, толи это GC еще не отстрелялся, толи сама программа такая "хорошая".
Кстати на си в принципе можно работать с полностью статичным распределением памяти. Когда заранее все выделено и сломаться абсолютно не на чем. Так работает всякая мелкая эмбеддовка, например. И это заметно повышает надежность: если нет динамических выделений памяти, свопа, и все *заранее* получено - то и сломаться оно в рантайм уже не сможет. Потому что не на чем. Нет утечек. Нет отказов выделения памяти. Абсолютно. Потому что нечему и некуда (функций *alloc может вообще не быть доступно). А жабисты такое как я понимаю принципиально не могут. Потому что за жабистов уже заранее решили как им следует управлять памятью, кхе-кхе.
> и некоторым даже их хватает чтобы криво написать программу.
Криво написать программу можно на любом языке. Что вообще за идиотская манера верить в серебряные пули которые якобы от всего спасут? Если кто-то не умеет думать - это НЕ ЛЕЧИТСЯ.
>> memory leak,
> Память у ява-программ течет так что дай боже. Чуть иначе
> чем у сишных, но это уже детали. А GC делает
> отлов этого факта сложнее на глаз - когда видно что прога
> жрет кучу памяти и жрач растет еще и фиг просто так
> поймешь, толи это GC еще не отстрелялся, толи сама программа такая
> "хорошая".Просто некоторых программеров не учили пользоваться профилировщиком, который покажет всю карту выполнения программы и ненужные долгоживущие объекты, которых наплодили почём зря.
> Кстати на си в принципе можно работать с полностью статичным распределением памяти.
Ты не поверишь, но на Java тоже.
> Когда заранее все выделено и сломаться абсолютно не на чем. Так
> работает всякая мелкая эмбеддовка, например. И это заметно повышает надежность: если
> нет динамических выделений памяти, свопа, и все *заранее* получено - то
> и сломаться оно в рантайм уже не сможет. Потому что не
> на чем. Нет утечек. Нет отказов выделения памяти. Абсолютно. Потому что
> нечему и некуда (функций *alloc может вообще не быть доступно). А
> жабисты такое как я понимаю принципиально не могут. Потому что за
> жабистов уже заранее решили как им следует управлять памятью, кхе-кхе.См. JavaCard. Это, кстати, технология, от которой отказались в Голландии, заменив нативной поделкой. Дешёвая нативная поделка смарткарты (без процессорного чипа, с одной лишь ПЛМ и обвязкой) быстро стала предметом хакерской атаки, выполненной довольно успешно.
Хотят, чтобы им народ нахаляву дофига тестов написал :)
> Хотят, чтобы им народ нахаляву дофига тестов написал :)Для ява программ то? Гуйных? Таких программ на всю планету - полторы штуки, и то почти никто ими не пользуется. Есть великий смысл заморачиваться их тестированием? oO
> Таких программ на всю планету - полторы штуки...Я видел планету, где Java-GUI программами пользуется 20% населения уже около 10 лет и очень довольны и никуда мигрировать не хотят.
Помнится, один раз только задали вопрос: "А будет ли оно работать под Линуксом?".
>> Хотят, чтобы им народ нахаляву дофига тестов написал :)
> Для ява программ то? Гуйных? Таких программ на всю планету - полторы
> штуки, и то почти никто ими не пользуется. Есть великий смысл
> заморачиваться их тестированием? oOДоа? "Число пользователей Opera Mini во всем мире превысило 76,3 млн. человек".
Может в этом направлении нужно двигаться?
Тестировать GUI скриптами - не думаю что такая халява будет достаточно эффективной.