so far, it's "easy" to test something, but this time I need to test an algorithm based on database source. The database should be filled for that, but is there a good, working way to do it?
What you are describing is really an integration test.
You would need to ensure that your test can set up the required data and clean up after itself to keep the tests repeatable. I normally create the database / tables as part of the test set-up, then drop them when I'm done, which is easier than trying to get a table back into a particular state.
Related
My problem is I'm using a HUGE web application (a school system), with no documentation for the internal logic. I need to make a bulk update of a particular value, but I don't know what tables in the MySQL database contain the relevant data to update. The app it's self runs from php. Is there an easy way to compare the database before I do an operation and after I do it so I can see what tables are effected? I tried using a diff comparing tool on the dumped sql before and after, but the database is so huge it's really impractical to use, wondering if there is something better or if I can just configure php somehow to log any mysql operations from whatever file happens to trigger them.
You may want to run the performance tool from the mysql workbench and look at the performance reports/statement analysis. This will work if you pick a time when the system is not being used and then run some function in the web that updates the tables with the values you need to change. Look at the performance table before and after you run your experiment and look for those sql statements which show use. It's not perfect, but this will at least help you begin to hone in on the data you're looking for. The big 'gotcha' here is if the value you want to change is dynamically derived during the query process. Then you'll have to understand how the derivation works and the source columns. But, again, this will give you a brute-force starting place.
So I have an old website which was coded over an extended period of time but has been inactive for 3 or so years. I have the full PHP source to the site, but the problem is I do not have a backup of the database any longer. I'm wondering what the best solution to recreating the database would be? It is a large site so manually going through each PHP file and trying to keep track of which tables are referenced is no small task. I've tried googling for the answer but have had no luck. Does anyone know of any tools that are available to help extract this information from the PHP and at least give me the basis of a database skeleton? Otherwise, has anyone ever had to do this? Any tips to help me along and possibly speed up the process? It is a mySQL database I'm trying to use.
The way I would do it:
Write a subset of SQLi or whatever interface was used to access the DB to intercept all DB accesses.
Replace all DB accesses with the dummy version of yours.
The basic idea is to emulate the DB so that the PHP code runs long enough to activate the various DB accesses, which in turn will allow you to analyze the way the DB is built and used.
From within these dummy functions:
print the SQL code used
regenerate just enough dummy results to let the rest of the code run, based on the tables and fields mentioned in the query parameters and the PHP code that retrieves them (you won't learn much from a SELECT *, but you can see what fields the PHP code expects to get from it)
once you have understood enough of the DB structure, recreate the tables and let the original code work on them little by little
have the previous designer flogged to death for not having provided a way to recreate the DB programatically
There are currently two answers based on the information you provided.
1) you can't do this
PHP is a typeless language. you could check you sql statements for finding field and table names. but it will not complete. if there is a select * from table, you can't see the fields. so you need to check there php accesses the fields. maybe by name or by index. you could be happy if this is done by name, because you can extract the name of the fields. finally the data types will missing. also missing: where are is an index on, what are primary keys, constrains etc.
2) easy, yes you can!
because your php is using a modern framework with contains a orm. this created the database for you. a meta information are included in the php classes/design.
just check the manual how to recreate the database.
A component of a website I'm building requires a user to enter a unique code in a form which is then verified as being a valid code by comparing it against a predetermined list of several million generated codes. How can I do this to provide instant feedback to the user?
Originally I was planning to check all of the submissions in a batch job overnight, but the client would like users to be informed whether they have a valid code immediately.
Is it more efficient to build a trie structure, store the generated codes in a database table, or use some other approach?
Using a MySQL table for this purpose is absolutely the right thing to do. MySQL has no problem looking up an entry in a few milliseconds from a multi-million-row table if you index it correctly. In fact, a MySQL table index is pretty close to a pre-programmed trie structure, with all the hard work, concurrency, edge cases, and debugging done for you.
If you build some other kind of lookup system, you'll have to sort out such things as persistence, maintenance of the data, and all.
I'm currently trying to use PHPUnit to learn about Test Driven Development (TDD) and I have a question about writing reports using TDD.
First off: I understand the basic process of TDD:
But my question is this: How do you use TDD to write a report?
Say you've been tasked to write a report about the number of cars that pass by a given intersection by color, type, and weight. Now, all of the above data has been captured in a database table but you're being asked to correlate it.
How do you go about writing tests for a method that you don't know the outcome of? The outcome of the method that correlates this data is going to change based on date range and other limiting criteria that the user may provide when running the report? How do you work in the confines of TDD in this situation using a framework like PHPUnit?
You create test data beforehand that represents the type of data you will receive in production, then test your code against that, refreshing the table each time you run the test (i.e. in your SetUp() function).
You can't test against the actual data you will receive in production no matter what you're testing. You're only testing that the code works as expected for a given scenario. For example, if you load your testing table with five rows of blue cars, then you want your report to show five blue cars when you test it. You're testing the parts of the report, so that when you're done you will have tested the whole of the report automatically.
As a comparison, if you were testing a function that expected a positive integer between 1 and 100, would you write 100 tests to test each individual integer? No, you would test something within the range, then something on and around the boundaries (e.g. -1, 0, 1, 50, 99, 100, and 101). You don't test, for example, 55, because that test will go down the same code path as 50.
Identify your code paths and requirements, then create suitable tests for each one of them. Your tests will become a reflection of your requirements. If the tests pass, then the code will be an accurate representation of your requirements (and if your requirements are wrong, TDD can't save you from that anyway).
You don't use the same data when running the test suites and when running your script. You use test data. So if you want to interact with a database, a good solution is to create a sqlite database stored in your ram.
Similarly, if your function interacts with a filesystem, you can use a virtual filesystem.
And if you have to interact with objects, you can mock them too.
The good thing is you can test with all the vicious edge-case-data you think of when you write the code (hey, what if the data contains unescaped quotes?).
It is very difficult, and often unwise, to test directly against your production server, so your best bet is to fake it.
First, you create a stub, a special object which stands in for the database that allows you to have your unit tests pretend that some value came from the DB when it really came from you. If needs be, you have something which is capable of generating something which is not knowable to you, but still accessible by the tests.
Once everything is working there, you can have a data set in the DB itself in some testing schema -- basically, you connect but with different parameters so that while it thinks it is looking at PRODUCTION.CAR_TABLE it is really looking at TESTING.CAR_TABLE. You may even want to have the test drop/create table each time (though that might be a bit much it does result in more reliable tests).
I'm building the front end of a website that'll be holding data for users. Type of data is name, email, ethnicity, income, pets etc etc. Each person can have a partner (with the same questions) and an infinite number of children (names, dob, gender etc). The user can sign up, and then must be able to log in in the future to update their details if necessary.
The problem I'm having is things are just getting really messy. It all starts with validation have loops to check how many children there are and add then redisplay and set up validators if there is an error. Inserting all the data is easy enough, but my insert_user function has 30 paramaters so far.
Everything's getting annoying and frustrating. Is there an established way to deal with data like this? I'm thinking propel or doctrine may help, and I've had a play with PEAR's HTML_QuickForm with limited success (it can't handle things like "select your ethnicity" and an input for "other" or unlimited children)
I'm sure I'm not the first to have this trouble so what to others do?
Have a look at Symfony, it will make your life a lot easier. Your datamodel here is pretty simple, but be prepared to learn how Symfony works.
http://www.symfony-project.org/
This is the simplest tutorial I know of : http://articles.sitepoint.com/print/symfony-beginners-tutorial : it should get you up and running in a couple of hours.
When I deal with something like this I start with trying to come up with a good model to make it less complex.
For example, if you have server functions, in php, then you can use ajax calls, in javascript to deal with the display, so, you have separated concerns, so you can focus on having each side do what it does best.
If you want to keep everything in php, and just use form submission, then again, split the two parts so that the parts of the code that deals with display is separate from the api that deals with the database.
This is basically just an MVC structure.
That would be the best way to start, is to go back to your design phase, decide which languages you want to use, and separate the work.
Either way you end up with writing an API to get to the database, and the controller code (which handles getting requests and displaying them) doesn't care what type of database, if there is a database or any of those details, it wants to get the children for a particular person, so that request is given to the API and an array is returned.