Testing PHP project after coding is finished - php

I've got a PHP project to test. I've already (almost) finished coding the project and I didn't have any testing plan at the start. Being new to PHP, I thought I'd finish the coding and start testing afterwards. As unit testing needs to be done as you go along, what is my other alternative for a test? I want something like a complete system test rather than unit by unit.
I've got around 30 PHP script files, 5 of which are class scripts.
NB It needs to be a formal way of testing, rather than trying to hack it.

I believe your aim behind the test is more "academic" than practical. So testing by friends doesn't really help much. Having said that you have already completed coding the project so if you wanted to unit test using PHPUnit or SimpleTest you will have to go back and start coding the unit test cases.
I think the best option here would be to create a "formal" test document. There are tons of resources out there for how to do this. Basically it will have:
Url
Action
Expected Result
Observed Result
If your expected and observed results match, then that test case is passed.
You can create as many test cases as you want for your project based on these basic guidelines.

Testing has it's different role in SDLC. There are various aspect on which testing could be done. Like:
Smoke Testing
Functionality Testing
System Testing
Retesting
Regration Testing
Preformance Testing
and many more testing technique are there for testing a web application.

Just upload the project and ask someone to test it.You have to test it or get it tested.There is no other way
You can also run a simple scanner(like burp or acunetix) to test whether website can be hacked or not.

You can use a web app scanner,
There are some F/OSS out there such as;
Skipfish - CLI Windows/Linux
Netsparker Community Edition - Windows - Light version of a commercial scanner
List of web app security scanners - commercial and free

Related

TDD What should be the order of unit testing, integration testing and acceptance testing?

I am doing TDD for a project using PHP. Until now, I write unit tests, make them fail and then write the least amount of code to fulfill the test. After the project has been completed, I write acceptance testing using CasperJS.
Of late I have been looking into Codeception and Behat and some other test frameworks and have been reading about different types of tests like Unit Testing, Integration Testing et al.
Nowhere could I find the correct order of testing.
What I want to know is when I sit down to design the project, I do:
Requirement Analysis
Technology Stack Selection
Enumerate the Resources/Business Entities
Then decide what goes into Models, what stays as Services etc.
Database Design
Do the list of Models, Controllers, Services necessary
Write tests before writing the individual classes using phpUnit
Once API is ready, write CasperJS tests to verify behavior.
While this is not exact, but a good indication of how I run my shop. So, where do integration testing and behavior testing fit in?
This really feels like an opinion based question, so don't be surprised if it gets closed for being such. There really isn't a perfect answer, and deciding how and when to write tests really depends on the project and you.
You could try to work out all the user stories and behaviors and write the acceptance tests before your step 3. This could help illuminate dark corners in the plan.
Or, you could write acceptance tests before starting a feature. This could help to get you in the mindset of what needs to be done with a given feature, its scope, and edge cases.
Or, you could write acceptance tests after the project is finished. This could serve as a final check list of expected behaviors before handing off to the customer for whatever acceptance testing they want to do.
I'm sure there're other points in your workflow where writing acceptance tests might be appropriate, but these are three points where I've found myself writing such tests. IMO, the best place is right before starting a feature. At that point, I have a user story, I'm familiar with the code I've already written, and I have an idea of what the new code is expected to do.
The acceptance tests can be organized to guide coding in the same way unit tests do, but at a broader level. Still iterate through "write failing test, write code to make test pass, write failing test," but also have a larger loop driven by the acceptance tests. Once you get to a point in the inner cycle where you think you'll have a passing acceptance test, check by running the whole suite.
There is another way in which you can ask "where integration and behavior testing fit in," and that's in the sense of "where does that testing fit in with the rest of my testing and code?" This is a little less grey. Unit testing should be run often. The entire unit test suite. Often. So it needs to be incredibly fast. You should be able to know if you broke something internal to your project immediately.
Integration tests are there to verify the ins and outs are working as expected. Outside of your app, your dependencies aren't going to change, and if they do, it should be a big deal that you should be aware of. So there's a clear demarcation between your code and their code. Your unit tests can carry you all the way to that interface. Integration tests verify that the interface you coded for, really is the interface they're providing. You don't need to run these with every little code change. You do need to run them, but maybe only every commit. They can be slower.
Acceptance tests are similar to integration tests, only rather than enlisting an external dependency to verify the interfaces match, they define the interface. You could hold of on running them until near release, but the more often you can run them, the more value they actually provide.
YMMV.

Continuous Integration Server: Hudson or Sismo?

We're considering using a CI server soon.
From my reading, I've found that Sismo and Hudson were available for PHP project.
Considering that we're actually using GIT and PHPUnit, what are the big difference between Hudson and Sismo that we should know in order to make the best choice for our situation ?
Thanks
The language match is not key in your hunt for the best CI server; it's all the features around:
source control
concurrent build
trigger build
notification
Even for simple project, Jenkins (the new name for Hudson) is easy to use and quick to install. Then it is really easy to scale Jenkins up by adding more nodes (satellite machine that can execute build) when you need to. Also Jenkins has hundreds of plugin for numerous task.
Have a look at Bamboo, Jenkins, TeamCity, and CruiseControl Features to compare some of the features of the big names (you might actually want to consider Bamboo, TeamCity or Cruise Control over Jenkins)
I would lean towards Sismo since it matches the language of the project you are developing (PHP) and can be ran from just a single PHP and config file. Then you don't have to deal with having a java environment just for Hudson.
There is a really good php-integration for Jenkins by the phpunit inventor Sebastian Bergmann. You should really have a look at it.
As far as I see the biggest downside of Sismo is, that is not a "real" CI server, but more a build-and-report-environment, because you need to trigger the builds yourself (or let something trigger it).
I'll preface this by saying that I haven't used sismo.
We use Hudson with applications being built & tested in both Java and PHP. It has a nice plugin system, and getting it up and running on a centOS box took about 15 minutes yesterday. (We had to move it from one box to another).
For PHP Hudson integrates with both PHPUnit and Selenium so we run both unit tests and functional tests against the same codebase. Hudson has a great 'one-click' plugin system that really lets you customize your installation.
One thing we had to get a plugin for was sending an email on every build whether successful or not. Hudson by default will only email when your build goes from good (tests pass) to bad, from bad to good, or repeatedly bad. This means it will not send an email for every build if 2 builds in a row were successful. The email plugin solves this but it was confusing to uncover that.

PHP Automated Deployment and Testing

I asked a question here on automated deployment of automatically deploying java code.
Our back-end Java API is accessed by a PHP web app. It would be nice to be able to automatically deploy this web app (along with static files like CSS, JS and images) to our web server while performing automatic testing on PHP code. Is there something similar to this for PHP?
I also wonder if as part of this automated testing you can check that each actual page loads without a fatal error. I am sure I read about a google project which allows you to write page tests e.g. click on link a, go to page b etc etc.
Thanks
You may want to look into using Phing for deployment which has features that allow testing with PHPUnit and/or SimpleTest
Maybe this question handling deployment strategies can help you.
Additionally, but maybe gone too far, tools like cruise control may help you to apply continuous integration, too.
PHPUnit with ant was my way to go for automated testing, which could be a vaild option for you, too since you're obviously using some java already :)
Since you're working with Java, you might consider using Hudson (also mentioned in your other question), which has the ability to execute build tasks consisting of several 'steps' One step step could be unit testing your Java App, another unit testing a PHP app, yet another deployinhg Java app, and another deploying a PHP app (and you could add some more ;P )
It has a Maven plugin, so you could actually use your existing Maven scripts.

Solutions for testing entire features of an app

EDIT: to clarify - I am asking for advice on both unit testing and user interface testing.
Currently, I don't use TDD. While I am developing an application I am constantly testing what I am working on. Testing iteration could be anything from minor function changes to entire models. I try not to code too much before I test. I like instant feedback.
Of course, with experience I can see potential problems or bugs occurring as I'm coding.
BUT, after an application is complete I will usually go through the entire app on the frontend and ensure all functions are working as expected. This means literally everything. Every add/edit/delete, sort, filter, even broken links and such.
This can take a lot of time sometimes but it does ensure my work hardly ever contains bugs after deployment.
However, I'm looking for a more standard solution. What do experienced developers do? Assume for a moment I am a single developer and so do not have a testing department etc
Do you hire beta testers (no good if app is sensitive to public use)?
Is it viable to build a series of 'general' unit tests which can for example test ALL sorting, filter functions. One for testing ALL add/edit/delete functions.
Love to hear your feedback. Will be changing the way I develop based on suggestions.
Of course as David said : Unit-testing for models and helpers, of course.
and I need to add Selenium
Selenium is a robust set of tools that supports rapid development of
test automation for web-based
applications. Selenium provides a rich
set of testing functions specifically
geared to the needs of testing of a
web application. These operations are
highly flexible, allowing many options
for locating UI elements and comparing
expected test results against actual
application behavior.
which is amazing :
watch the 2 min intro
http://seleniumhq.org/movies/intro.mov
How Selenium Works
Testing with PHPUnit and Selenium
Unit-testing for models and helpers, of course.
But you can do unit-testing on "page-requests", as well. See, for example:
Content with Style - Unit testing controllers with Zend Framework
That's a step towards integration testing. But for issues of layout and visual aesthetics, you're pretty much stuck with walking-through each request with your browser.
Usually what you code works is not that the problem, very nice if you also write tests for it. The problem is that you need to test the integration of your changes every time you make commit.
If you like instant feedback,as I do, probably you should have a look at Continuous Integration.
I've started using Hudson as CI server and I am not regretting it!

Unit Testing a Website

I'm curious to see how other developers go about testing their web sites. PHP specifically in my case, but this probably spans multiple languages. I've been working on a site for over a year now, and I'd really like to automate a lot of the regression testing I do between versions.
This specific site is in CodeIgniter, so I have some tests for my models. I'd like to move beyond just testing those though. However, this is an issue even non-MVC developers have had to tackle I'm sure.
Edit: I think the functionality that would satisfy a lot of my test desires is the ability to assert that paramters have a specific value at the end of the script processing. In my case a lot of logic is in the controller, and that's the main area I'd like to test.
For actual unit testing without testing the UI, you should just test the functions in the model. Most of your functionality should be in there anyways.
You might want to have a look at Selenium for testing the UI of your site. It can record your actions and play them back, or you can edit the scripting directly.
(source: seleniumhq.org)
Have you tried Fitnesse ?
It helps on creating Acceptance tests. They are specially useful for websites, which doing this kind of tests are a pain.
There are a couple of videos from unclebob inside the webpage too. The good thing is that Fitnesse is not restricted for website testing, so your knowledge about using it can be used with other apps too.
The project I'm working on is a Desktop APP written in c++ that uses Fitnesse tests.
But if you meant unit testing the models (which I think you didn't), they can be create using the phpunit lib. I think the ZEND framework has a similar lib for that.
You might want to check out PHPUnit
http://www.phpunit.de/manual/current/en/
I have started using it on my PHP projects and it's very easy to work with and very powerful. In particular, learn and use mocks:
http://www.phpunit.de/manual/3.0/en/mock-objects.html
Mocking is especially important when unit testing applications that do database operations.
Take a look at TOAST. It's build specially for CodeIgniter. It uses CI infrastructure, so you can run all test tests via a browser and results are displayed back as a web page (HTML). It's very simple to use.
I suggest you test your Controllers as well. Testing model is ok, but model is just the DB storage. Controllers contain all the "business logic" and are the place where most things go wrong.
One of the best ideas I've heard of, as far as testing web apps go, was to create a script that would go over all the pages in the site and check them for differences from the previous scan, letting you accept changes and fix regressions.
Generally speaking, automatic testing of GUI applications (websites are GUI apps) is difficult and usually unnecessary. Unit tests work best with simple libraries.
I use Canoo WebTest. It is the best free web site unit test framework out there. It is entirely scriptable with XML and requires no browser so it can run from a build server.
We modified Waiter (Ruby). It plays back "scripts" of URLs and Form Filling to IE and we have added a script "command" to take a Screen Capture; the screen capture image is compared against a Known-Good-Image (i.e. a Master Image) and if that image is different it is logged (basically a Web page of such results is prepared) and "a human" does a review of the Master / Test image. Obviously there are two outcomes at that point - "The difference is intentional" or "There is an incorrect change". In the first instance the Master image is replaced with the New Image; in the second we go fix the bug, and the change will be included in the next test run

Categories