Blog
Peter's blog
 |
ing. Peter C. Verhage Professional Services Consultant |
 |
| Peter is a senior developer in our Vlissingen office. He's the lead architect of the ATK framework, has a passion for clean code and architecture, and occasionally flirts with Ruby. |
Woensdag, 15 november 2006ATK gets true test database support
ATK has built-in test support for a while now. But until now this didn't include support for adding, updating and/or removing test data in such a way that the development/production database isn't littered with test data. You can make use of the mock database class, but then you can't really test if the query you wrote actually works the way it's supposed to work. And you can ofcourse remove the test data in your test by writing the necessary code to do so, but this means a lot of extra work.
As of today there's a third option, you can make use of ATK's built-in test database support. How it works When the ATK test-suite starts it first clones the development/production database structure in a test database. Only the structure will be cloned, so you end up with an empty test database. After this the test-suite will start running the test-cases for your application. Each test-case can consist of one or more test methods. Before each test method is called so called fixtures will be loaded into the database. Fixtures are a way of organizing your test data. They are a way of describing the records for your test database. After each test method has run the data will be rollbacked (or deleted depending on the capabilities of your database). Not only the data of the fixtures will be rollbacked, but also data that's been added inside the test method. This way you are in full control of the data inside the test database. Fixtures Fixtures are stored in files. At this time there are two kinds of fixtures ATK supports. First of all ATK supports YAML fixtures and secondly ATK supports PHP fixtures. For each table in your database you can create a seperate fixtures file. Depending on the file extension (.yml or .php) ATK will automatically know how to process the fixtures file. A fixtures file can contain zero or more records. The records will be literally added to the database, so they won't be added with the addDb function of a node. This means that even sequence fields need to be assigned values. The reason for this is that this way it's much easier to create relationships between records, because you always know the exact key of the record(s) you want to reference. Fixtures can also be assigned a name, this makes it possible to retrieve the fixture data by name inside your test-case. In the future ATK might also support other kinds of fixtures, for example CSV fixtures. How-to I will soon be posting an how-to for using ATK's test database support on the ATK wiki. It will be available in the how-to section. Until then you can e-mail me if you have any questions. Share         Reacties
Geeft reacties weer als
(Lineair | Samengevoegd)
Hello Peter!
Do you have some example for filter combo-boxes in cascade, I mean, I have countries, states, counties, and cities. I would like that if I select a country, next combo box shows only states of that select country, and etc. I had surfed and dive into the forum but I couldn't get it... So I'm so sad about it, because ATK seems to me a great framework. I really hope you can helpme, thanks in advance. Best regards Franz
It depends on where your data comes from. Are the countries, states and cities stored in the database? If so you can use multiple atkOneToManyRelations what you would normally do. However you have to register some dependencies between the different relations.
You can do this by calling $countryAttr->addDependee('state') etc. What this does is make sure that the state attribute gets refreshed once you select a different country. This means we are half way there. For the next part you need to add a filter on the state attribute that filters the states based on the selected country. You can can do this by calling $stateAttr->setDestinationFilter("state.country_id = '[country.id]'"); The same goes for the city selection. If you don't retrieve the countries or states from the database you can use the same dependency mechanism but you then have to override the edit methods for the state and city attributes. You can do this by creating a custom (sub-)class for the attributes or you can do this in the node by creating a method called _edit. Inside this method you have access to the current record and you can use that to filter the possible options. |
