Сообщений в теме: 9

[hooliganka]

Начнем с того, что я новичок, и может то, что я хочу не есть правильно с точки зрения организации тестов.

Представьте, что есть система которая позволяет добавлять Пользователей, Компании и Клиентов.

Мне, чтобы добавить Клиента нужен Пользователь и чтобы добавить Компанию нужен Пользователь. То есть у нас есть 2 кейса, где изначально требуется создать Пользователя, а потом уже осуществлять добавление других элементов.

Можно конечно прописать создание пользователя в кейсе добавления Компании и в кейсе добавления Клиента. Но было бы лучше просто создав кейс добавления пользователя подключать его по необходимости и иметь возможность использовать данные (такие как имя, логин или пароль Пользователя) из этого кейса в других.

Проблема в том, что я не представляю как это сделать при помощи PhP.

Приму любые замечания по лучшей организации тест-кейсов.

[KaNoN]

Начнем с того, что я новичок, и может то, что я хочу не есть правильно с точки зрения организации тестов.

Представьте, что есть система которая позволяет добавлять Пользователей, Компании и Клиентов.

Мне, чтобы добавить Клиента нужен Пользователь и чтобы добавить Компанию нужен Пользователь. То есть у нас есть 2 кейса, где изначально требуется создать Пользователя, а потом уже осуществлять добавление других элементов.

Можно конечно прописать создание пользователя в кейсе добавления Компании и в кейсе добавления Клиента. Но было бы лучше просто создав кейс добавления пользователя подключать его по необходимости и иметь возможность использовать данные (такие как имя, логин или пароль Пользователя) из этого кейса в других.

Проблема в том, что я не представляю как это сделать при помощи PhP.

Приму любые замечания по лучшей организации тест-кейсов.

Зачем вы заморачиваетесь изначально, что нужно вызвать один кейс из другого? Можно поступить более рационально. Например, создание пользователя, добавление различных элементов вынести в отдельные функции, которые потом будут вызываться из тестов. В результате, каждый тест вы можете рассматривать как цельный независимый юнит, который не зависит от других. А созданные вами функции могут использоваться многократно в различных тестах, особенно, если вы вынесите в функции достаточно общие операции.

А РНР - это просто очередной язык программирования и никаких особенностей в этом он не предоставляет.

[kvis_qa]

Начнем с того, что я новичок, и может то, что я хочу не есть правильно с точки зрения организации тестов.

Сорри за оффтоп:) Первый свой пост на форуме профессионалы пишут обычно - только если это их форум:)
Желаю успехов на ниве авто-тестирования в частности - и контроля качества в целом:)

[anastas]

У меня подобная ситуация, и меня интересует вопрос оптимальной организации тестов.

Сейчас у меня тестирование организовано следующим образом:
Каждый тестовый случай выполняется отдельной функцией, тестовые случаи для одной функциональности объеденены в тестовые классы.
Затем в файле TestSuite.php эти классы вызываются в нужной последовательности.

Когда тестов стало больше, то возникла необходимость вызывать не весь класс, а только одну функцию из класса.
В идеале думаю, что наберется какая-то база стандартных use-cases, и в зависимости от того, что требуется протестировать и какое тестирование провести будет запускаться определенный ранее созданный TestSuite_XXX.php. При этом один и тот же тест может принадлежать нескольким test-suites.
Может такая организация неправильная?
Может у кого-то есть большая база тестов, поделитесь каким образом вы их организуете? Каким образом запускаете test-suite?

Заранее всем спасибо за внимание и ответы.

[KaNoN]

У меня подобная ситуация, и меня интересует вопрос оптимальной организации тестов.

Сейчас у меня тестирование организовано следующим образом:
Каждый тестовый случай выполняется отдельной функцией, тестовые случаи для одной функциональности объеденены в тестовые классы.
Затем в файле TestSuite.php эти классы вызываются в нужной последовательности.

Когда тестов стало больше, то возникла необходимость вызывать не весь класс, а только одну функцию из класса.
В идеале думаю, что наберется какая-то база стандартных use-cases, и в зависимости от того, что требуется протестировать и какое тестирование провести будет запускаться определенный ранее созданный TestSuite_XXX.php. При этом один и тот же тест может принадлежать нескольким test-suites.
Может такая организация неправильная?
Может у кого-то есть большая база тестов, поделитесь каким образом вы их организуете? Каким образом запускаете test-suite?

Заранее всем спасибо за внимание и ответы.

Для PHPUnit есть такая штука, как группы. Их можно назначить для определенных методов. После этого PHPUnit можно запускать только для определенных групп (в его командной строке есть опция для этого). Это как раз позволяет запускать определенное подмножество тестов. И для этого отдельные файлы тест-сьютов не нужны просто.

[George.Ivanov]

Зачем вы заморачиваетесь изначально, что нужно вызвать один кейс из другого? Можно поступить более рационально. Например, создание пользователя, добавление различных элементов вынести в отдельные функции, которые потом будут вызываться из тестов. В результате, каждый тест вы можете рассматривать как цельный независимый юнит, который не зависит от других. А созданные вами функции могут использоваться многократно в различных тестах, особенно, если вы вынесите в функции достаточно общие операции.

Раз пошла такая тема, прокомментируйте, плз, ситуацию.
Запуская тест сначало прогоняется LogIn, потом браузер закрывается (как обычно при окончании теста "Command request: testComplete ... бла, бла, бла Killing Firefox") и открывается заново, чтобы открыть новую сессию и выполнить вторую часть теста.

Есть ли красивывй способ решить вопрос с проходом теста без обнуления сесси? Хотелось бы более объектно ориентированно писать тесты).
Начинал с вызова логина отдельной функцией внутри класса SomethingUsefull - эффект тот же.

<?php

require_once 'PHPUnit/Extensions/SeleniumTestCase.php';
require_once 'blah-blah\LogIn.php';


class SomethingUseful extends PHPUnit_Extensions_SeleniumTestCase
{

    function setUp()
    {
        $this->setBrowser("*chrome");
        $this->setBrowserUrl('https://www.address.com/');
    }

    public function testClickOnTheButton()
    {
        // Execution of LogIn test case.
        $logginner = new LogIn();
        $loginner.testSignIn(); 

        // Do something useful.
        $this->click("button");
        
    }
}
?>

P.s. использую связку NetBeans 6.9.1. (selenium 1.0.1) + PHP
Upd. пркачал selenium до 1.0.3 - проблема актуальна.

Сообщение отредактировал George.Ivanov: 16 февраля 2011 - 09:16

[George.Ivanov]

Вызов одного кейса из другого. Selenium+Php. Решение.

Использую связку NetBeans 6.9.1 (с подложенным selenium 1.0.3) + PHP5.3.3

Папки проекта.
Папка проекта New Folder содержит:
1. Selenium.php скаченный из selenium-server-standalone-2.0b2 лежавший в "selenium-remote-control-1.0.3\selenium-php-client-driver-1.0.1\PEAR\Testing\"
2. AuxiliaryClass.php
3. SomethingUseful.php
4. Папка Selenium с файлом Exception.php скаченный из selenium-server-standalone-2.0b2 лежавший в "selenium-remote-control-1.0.3\selenium-php-client-driver-1.0.1\PEAR\Testing\Selenium\"

Суть решения.
Создаётся "прослоечный" класс, который содержит все полезные часто повторяющиеся функции. Он наследуется от PHPUnit_Framework_TestCase. Соответственно классы тестов будут наследоваться от нашего промежуточного класса (я назвал AuxiliaryClass).
Этот AuxiliaryClass заполняем вспомогательными функциями, которые не начинаются с test, и значит не будут грузиться в новой сессии браузера. За исключением названия, эти функции - полноценные тест кейсы (напр. логин). Там же определяем свойство класса (protected $selenium;)
В "боевых" тест кейсах, подключаем вспомогательный класс (require_once) и в нужный момент вызываем соответствующую функцию.

Пример файлов

AuxiliaryClass.php

<?php

require_once '\New Folder\Selenium.php';
require_once 'PHPUnit/Extensions/SeleniumTestCase.php';

class AuxiliaryClass extends PHPUnit_Framework_TestCase  
{
    protected $selenium;

    public function lignIn()
    {
        $this->selenium->open("/");
        $this->selenium->type("form_username", "tester");
        $this->selenium->type("form_password", "test");
        $this->selenium->click("Login");
        $this->selenium->waitForPageToLoad("30000");
    }
}
?>

SomethingUseful.php

<?php

require_once 'PHPUnit/Extensions/SeleniumTestCase.php';
require_once 'New Folder/AuxiliaryClass.php';


class SomethingUseful extends AuxiliaryClass
{

    function setUp()
    {
        $this->selenium = new Testing_Selenium("*chrome", "https://www.address.com/");
        $this->selenium->start();
    }

    public function testClickOnTheButton()
    {
        // Execution of LogIn test case.
        $this->logIn();

        // Do something useful.
        $this->click("button");
    }

    public function tearDown()
    {
        $this->selenium->stop();
    }
}
?>

Получилась приятная, красивая такая схема. Прозрачно, весьма объетно ориентированно, и что особенно ценно: работает.
"То, что не красиво, хорошо работать не будет." (с)
Возможные проблемы решаются здравым смыслом и гуглом.

Хотелось бы услышать комментари, коллеги!

[KaNoN]

По-моему, слишком смешана бизнес-логика и тестовая логика. Например, тот же setUp метод имеет смысл как раз выносить в базовый класс, так как инициализация селениума нужна практически каждому тесту.

Метод для залогинивания лучше держать не в расширенном классе теста, а скорее всего лучше вынести в отдельную группу классов, отвечающих именно за бизнес-логику.

Это нужно учитывать, иначе со временем, когда число методов будет уже большим, будет каша.

[George.Ivanov]

С "setUp метод имеет смысл как раз выносить в базовый класс" согласен полностью.
В принципе, на разделение "класс тест кейс" - "базовый класс проекта" - "технический класс селениума" тоже согласен. Но я не знаю, как решить этот вопрос без трёхслойного наследования.

[KaNoN]

В принципе, на разделение "класс тест кейс" - "базовый класс проекта" - "технический класс селениума" тоже согласен. Но я не знаю, как решить этот вопрос без трёхслойного наследования.

А что не так? Базовый класс для тестов вам нужен для расширения стандартного функционала путем добавления общих для вашего проекта действий, как инициализация селениума и каких-то глобальных структур данных для вашего проекта. То есть вам нужен свой базовый класс тестов "с блекджеком и шлюхами", заточенными под ваши нужды. А уже каждый конкретный тест-кейс использует базовый класс для повторяющихся операций.

В таком наследовании нет ничего зазорного. Более того, вы избавляетесь от ряда копи-пастов. Пока что это только для 1-2 случаев, но для больших систем и просто для уже развившихся проектов, где уже много реализовано, таких случаев будет намного больше. Выносить повторяющиеся методы в базовые классы - это вполне нормально.