Комментарии 23
в php всего 8 типов данных, не хватает еще 2х:
1. float
2. resource
Второй можно рандомизировать тоже достаточно просто — tmpfile()/fclose()
1. float
2. resource
Второй можно рандомизировать тоже достаточно просто — tmpfile()/fclose()
метод getFunction на самом деле возвращает строку.
var_dump(create_function('$a,$b', 'return «ln($a) + ln($b) = ». log($a * $b);'));
выведет: string(9) «lambda_1»
Что бы вернуть функцию нужно написать чтото типа:
Но это работает с версии 5.3
var_dump(create_function('$a,$b', 'return «ln($a) + ln($b) = ». log($a * $b);'));
выведет: string(9) «lambda_1»
Что бы вернуть функцию нужно написать чтото типа:
public static function getFunction()
{
return function ($a, $b) { return "ln($a) + ln($b) = ".log($a * $b); };
}
Но это работает с версии 5.3
public static $allowedTytes = array(0,1);Антипаттерн «Magic numbers» же.
Почему бы не использовать константы класса?
const T_INTEGER = 0;
const T_STRING = 1;
const T_ARRAY = 2;
const T_OBJECT = 3;
const T_BOOLEAN = 4;
const T_FUNCTION = 5;
const T_NULL = 6;
public static $allowedTytes = array(self::T_INTEGER, self::T_STRING);
1) Поставленная задача решается совсем не Fuzzing'ом. А честным написанием тестов на типы входных данных. Без какого либо «рандомного» поведения. Fuzzing нужен для обнаружения ошибок, которые сложно поймать статическим тестами.
2) Если задача все таки Fuzzing, то генерировать нужно рандомные значение, которые могут генерировать весь спектр значений. Так, например, строка, генерируемая через uniqid будет содержать только ограниченный набор символов и иметь постоянную длину, тем самым не покрывая огромное множество вариантов
3) Задание параметров через наследование — не лучший вариант.
4) Если использовать getRand() в getArray() без ограничения на тип, то можно легко упасть в очень длинный цикл при $allowedTytes = array(0,1,2);
2) Если задача все таки Fuzzing, то генерировать нужно рандомные значение, которые могут генерировать весь спектр значений. Так, например, строка, генерируемая через uniqid будет содержать только ограниченный набор символов и иметь постоянную длину, тем самым не покрывая огромное множество вариантов
3) Задание параметров через наследование — не лучший вариант.
4) Если использовать getRand() в getArray() без ограничения на тип, то можно легко упасть в очень длинный цикл при $allowedTytes = array(0,1,2);
Было бы неплохо вдовесок к этому сделать генератор тестов — который определял бы список методов класса или обычных функций, с помощью рефлексии или doc-блоков определял бы требуемое кол-во передаваемых параметров и генерировал код теста.
> Все, кто разрабатывает на php, да и вообще на любом другом языке программирования с нечеткой типизацией, сталкивались с подобной проблемой:
> PHP Notice: Undefined index: test in /var/www/Testing.php on line 171
Проблема тут в чем? В сочетании 2 факторов: 1) низкой теоретической подготовки разработчиков (есть люди которые не читали даже начало мануала на php.net) и 2) тем, что по дефолту в PHP error_reporting != -1 и показываются не все ошибки. А, есть еще люди, которые не умеют использовать команду tail или аналогичное автоматическое средство мониторинга, но их мы за разработчиков даже не будем считать. Так вот, по моему проще стараться писать аккуратно и мониторить ошибки, чем этим непонятны классом тестировать все методы (как? кто код будет писать?) и ставить ненужные проверки в приватных методах например. Как говорится, пользователь — лучший тестер.
В общем, крайне сомнительное решение. Лучше все же поправьте error_reporting, настройте мониторинг и почитайте php.net — времени меньше уйдет.
А тестировать фаззингом стоит разве что код, который пришел вам от предыдущих программистов, индусов или начинающих разработчков.
Вообще, необходимость тестов — сложный вопрос, особенно в вебе, где крайне важна скорость написание и модификации кода.
> PHP Notice: Undefined index: test in /var/www/Testing.php on line 171
Проблема тут в чем? В сочетании 2 факторов: 1) низкой теоретической подготовки разработчиков (есть люди которые не читали даже начало мануала на php.net) и 2) тем, что по дефолту в PHP error_reporting != -1 и показываются не все ошибки. А, есть еще люди, которые не умеют использовать команду tail или аналогичное автоматическое средство мониторинга, но их мы за разработчиков даже не будем считать. Так вот, по моему проще стараться писать аккуратно и мониторить ошибки, чем этим непонятны классом тестировать все методы (как? кто код будет писать?) и ставить ненужные проверки в приватных методах например. Как говорится, пользователь — лучший тестер.
В общем, крайне сомнительное решение. Лучше все же поправьте error_reporting, настройте мониторинг и почитайте php.net — времени меньше уйдет.
А тестировать фаззингом стоит разве что код, который пришел вам от предыдущих программистов, индусов или начинающих разработчков.
Вообще, необходимость тестов — сложный вопрос, особенно в вебе, где крайне важна скорость написание и модификации кода.
Поясню задачу которая стояла пере домной.
Был проект, было много программистов. Программистам не осложняли жизнь чтоб они писали все эти проверки (да, ошибка), ибо в параллельно разрабатывалась система контрактов для всех классов(сервисов в проекте).
Мне потребовалось протестировать свой класс и контракт который я к нему написал.
Своим скриптом я прибил двух зайцев, первый это я протестировал то что я написал, второй — я протестировал работу контрактов и вообще всей системы которую мы разрабатывали. При первом запуске все сломалось, были варнинги и куча фатал ероров один за одним, которые же всем другим пришлось исправлять.
Был проект, было много программистов. Программистам не осложняли жизнь чтоб они писали все эти проверки (да, ошибка), ибо в параллельно разрабатывалась система контрактов для всех классов(сервисов в проекте).
Мне потребовалось протестировать свой класс и контракт который я к нему написал.
Своим скриптом я прибил двух зайцев, первый это я протестировал то что я написал, второй — я протестировал работу контрактов и вообще всей системы которую мы разрабатывали. При первом запуске все сломалось, были варнинги и куча фатал ероров один за одним, которые же всем другим пришлось исправлять.
> Вообще, необходимость тестов — сложный вопрос, особенно в вебе, где крайне важна скорость написание и модификации кода
Странное утверждение. Тестирование важно везде оно не влияет на скорость разработки (это скорее качества языка и разработчика). В вэбе важна безопасность прежде всего, а она как раз страдает от недостатка тестирования параметров
Странное утверждение. Тестирование важно везде оно не влияет на скорость разработки (это скорее качества языка и разработчика). В вэбе важна безопасность прежде всего, а она как раз страдает от недостатка тестирования параметров
/**
* получение null
* @static
* @return null
*/
public static function getNull()
{
return null;
}
если бы я мог предложить вам вакансию java-разработчика, клянусь честью, я бы предложил её такому достойному господину, как вы.
abstract class NullFactory implements ITypeFactory
$functions = get_defined_functions();
foreach($functions['user'] as $k=>$v){
$info = new ReflectionFunction($v);
$numberOfArgs = $info->getNumberOfParameters();
$numberOfRequiredArgs = $info->getNumberOfRequiredParameters();
$args = array();
for($i=0;$i<$numberOfArgs;$i++){
$args[] = tester::getRand();
}
call_user_func_array($v, $args);
}
Автотестинг всех объявленных функций )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование приложений методом Fuzzing