Take the 2-minute tour ×

So now I have come to the conclusion like many others that having some way of constantly testing your code is good practice since it enables fewer people to be involved (colleges and customers alike) by simply knowing what's wrong before someone else finds out the hard way.

I've heard and read some about Unit Testing and understand what it's supposed to do and all. The there are so many different types of bugs. It can be everything from web browser not being able not being able to send correct values, javascript failing, a global function messing up a piece of code somewhere to a change that looked good when testing it out but fails in some special case which was hard to anticipate. My simply finding these errors I learn to rarely repeat them again, but there seems to always be new bugs to be found and learnt from.

I would guess maybe the best practice would be to run every page and it's functions a couple of times, witness the result and repeat this in Firefox, Chrome and Internet Explorer (and all smartphones apparently) to make sure it works as intended. However this would take quite some time to do consider I don't work with patches/versions and do little fixes here and there a couple of times per week.

What I prefer would be some kind of page I can just load that tests as much things as possible to make sure the site works as intended. Basicly just run a lot of cURL's with POST-values and see if I get expected result. But how would I preferably not increase the IDs of every mysql rows if I delete these testing rows? It feels silly to be on ID 1000 with maybe 50 rows in total.

If I could build a new project from scratch I would probably implement some kind of smooth way to return a "TRUE" on testing instead of the actual page. But this solution would for the moment being have to be passed on existing projects.

My question
What would you recommend to be the best way to test my site to make sure that existing functions does their job upon editing the code? Should I consider to implement a lot of edits first, then test manually the entire code to make sure it still works? Is there any nice way of testing codes without "hurting" the ID columns?

Extra thoughs
Would it be a good idea to associate all of my files to the different parts of my site which they affect? For instance if I edit home.php I will through documentation test if my homepage's start works as intended since it's the only part of my site it should affect.

share|improve this question
Check out Selenium (Its Wikipedia article might be a better place to start). –  Yannis Rizos Sep 3 '12 at 10:46
Read about Regression Testing –  superM Sep 3 '12 at 10:46

2 Answers 2

up vote 4 down vote accepted

Look at a browser based testing framework like Selenium and Watin as Yannis suggested. You can use this to automate human-like interaction with your web pages, things like "check the heading is "X" when the page loads, enter "Test" in the text box, submit using the "OK" button and check the resulting page's heading has changed to "Y".

Like all automated unit tests, it becomes repeatable and faster to execute. If you change home.php, in the example you give above, just run the tests over the whole website and make sure there are no flow on affects. Most testing frameworks support the commonly browsers and even run them in parallel on multiple computers.

If you are interested in performance by YSlow can help identify performance issues (although I have not used it in some time). There are link validators, SSL security validators, security analysis tools and many other tools out there.

Do not forget traditional automated unit testing on your back end. It can help isolate errors rather than just saying this page didn't load correctly, for example.

If you are worried about polluting your production database with test data, this may or may not be a good idea in the first place. The risk that your tests could interfere with customers and their data, particularly if there are financial transactions or personally identifiable information (PII) involved, is something you and your management have to weigh up but I would recommend using a separate but identical staging or test environment instead. If you must run tests on a production system, make sure your test data is easily segregated from customer data and purge it after the test run.

share|improve this answer

ID's should not be a problem for you. You can always drop the database and recreate it when you need to.

Unit testing is something a little different than what you are after. Unit testing only makes sure that a unit of code does work right. That is all.

You need to do integration testing to make sure all units work right when integrated together.

You also can do automated GUI testing to simulate your operations like pushing a button on web browser.

share|improve this answer
I asume you mean all testing should be done in a testing enviroment with identical behavior to the live version, and therefor IDs won't matter? By GUI testing do you mean like the one Yannis suggested? –  Robin Castlin Sep 3 '12 at 10:56
Yes, that is the general way. If you want to use your development machine as deploy server, you can drop the database and create it before going live. Yes, there are good GUI testing tools, however they are not so easy to setup and use. Good unit and integration testing and manual GUI testing is enough most of the time. –  Mert Sep 3 '12 at 11:25

Your Answer


