К сожалению не могу уделить слишком много времени и разобраться полностью что к чему. Поэтому выдам набор мыслей - а там сам смотри - по делу или нет.
Скажу сразу - меня порадовали тесты. Странно, правда, что они лежат в папке www, а не отдельно. Я уж поначалу подумал, что в архиве тесты не включены.
В последнее время у меня начало скаладываться весьма негативное отношение к сильно раздутому setUp() методу. Я предпочитаю выделять методы, например _insertTestingRecords() и вызывать их там, где нужно. То есть я стремлюсь делать каждый тестовый метод в TestCase-е как бы полностью независимым, показывающим полный прецедент использования класса. Правда здесь трудно найти правильный баланс - многое зависит от опыта.
Например, есть тест newsTableModuleTest. Я бы предпочел не делать такой setUp, подходящий для всех тестов сразу:
PHP:
public function setUp()
{
$this->db = DB::factory();
$this->cleardb();
$this->newsTM = new newsTableModule();
$stmt = $this->db->prepare('INSERT INTO `news` (`id`, `title`, `text`) VALUES (?, ?, ?)');
$stmt->bindParam(1, $id, PDO::PARAM_INT);
$stmt->bindParam(2, $title, PDO::PARAM_STR);
$stmt->bindParam(3, $text, PDO::PARAM_STR);
$id = '1'; $title = 'test_title_1'; $text = 'test_text_1';
$stmt->execute();
$id = '2'; $title = 'test_title_2'; $text = 'test_text_2';
$stmt->execute();
}
Я думаю, что у меня получилось бы:
PHP:
function setUp()
{
$this->db = DB::factory();
$this->cleardb();
}
function testGetNews()
{
$this->_insertNewsRecord($id1 = 1, $title1 = 'some_title1', $text1 = 'some_text1');
$this->_insertNewsRecord($id2 = 2, $title2 = 'some_title2', $text2 = 'some_text2');
$newsTM = new newsTableModule();
$newsAR1 = $newsTM->searchById($id1);
$this->assertEqual($newsAR1->get('id'), $id1);
$this->assertEqual($newsAR1->get('title'), $title1);
$newsAR2 = $newsTM->searchById($id2);
$this->assertEqual($newsAR2->get('id'), $id2);
$this->assertEqual($newsAR2->get('title'), $title2);
}
function testGetNewsNotExist()
{
$newsTM = new newsTableModule();
$newsAR = $newsTM->searchById($id = 0);
$this->assertNull($newsAR->get('id'));
}
и т.д. Многое зависит от предпочтений. Но я лично очень привык использовать тесты в качестве документации, поэтому стараюсь описывать весь прецедент именно в тестовом местоде. Это позволяет сразу понять все, что происходит, иметь под рукой все инициализациооные данные, например, title1, text1 и т.д. А setUp() и tearDown() предпочитаю использовать для таких вещей, от которых могут пострадать другие тесты, например, очистка таблицы, как в случае с newsTableModuleTest.
Далее. Я также предпочитаю иметь все данные, от работы которых зависит тест в самом тесте. Поясняю на примере. sectionMapperTest зависит от файла /www/tests/config/map.xml, так? Нельзя ли было создавать этот файл прямо в самом тесте. Это повысило бы понятность теста:
PHP:
public function TestSectionMapper()
{
$xml = <<<EOD
<?xml version='1.0' standalone='yes'?>
<mapps>
<test>
<action name="bar">test.bar</action>
<action name="foo">test.foo</action>
</test>
</mapps>
EOD;
$xml_file_alias = 'configs/map.xml';
$file_path = TESTS_DIR. $xml_file_alias;
file_put_contents($file_path, $xml);
$mapper = new sectionMapper(fileLoader::resolve($xml_file_alias));
$this->assertEqual($mapper->getTemplateName("test", "foo"), "act.test.foo.tpl");
$this->assertEqual($mapper->getTemplateName("test", "bar"), "act.test.bar.tpl");
unlink($file_path);
}
public function TestSectionMapperFalse()
{
$mapper = new sectionMapper('');
$this->assertFalse($this->mapper->getTemplateName(null, null));
$this->assertFalse($this->mapper->getTemplateName('test', '__not_exists__'));
}
Насчет фреймворка ничего умного сказать не могу
. Так и не понял, где используются команды и View-классы. Вроди не в фильрах, да и не в core классе, кажется. Есть вопрос, почему только один fileLoader? почему не сделать classLoader, configLoader и т.д., а резолверы передавать в качестве стратегии? В остальном - наполнило чуток ранний Mojavi.
В целом неплохо, повышай тестовое покрытие. Посмотрим, что будет в 0.0.2
