My workplace consists of a lot of cowboy coders. Many of them are junior. Which coincidentally contributes to a lot of code quality issues.
I'm looking for suggestions on how to best wane my team into using TDD (we can start with Unit tests, and move into regression tests, and later more automated testing).
Ultimately, I want us to learn more quickly from our mistakes, and produce better code and breed better developers.
I'm hoping there are some practical suggestions for how to introduce TDD to a team. Specifically, what tools are best to choose in the LAMP (php) stack.
Sorry if this question is too open-ended.
After going through this process four times now, I've found that any introduction of TDD will fail without some level of enforcement. Programmers do not want to switch style and will not write their first unit test and suddenly see the light.
You can enforce on a management level, but this is time-consuming for all involved. Some level of this is necessary at the beginning anyway, but ultimately you will need automatic enforcement. The answer to this is to introduce Continuous Integration.
I've found that a CI Server is the ultimate keystone to any TDD environment. Unless developers know that something bad will happen if they don't write the tests, you'll always have cowboys who feel it's beneath them.
Make writing tests easy and the results visible.
Use a TestFramework with good documentation. like SimpleTest
If test depend on database contents, create a reference database that will be dropped and created at the beginning of a script.
Make a script that runs all test and shows the results on a standalone monitor or something that will make the test visible / easily accessable. (Running a command prompt is not an option)
I personally don't write test for every chunk of code in the application.
Focus on the domain objects in the application. In my case these are "price-calculation" and "inventory-changes"
Remind them that they are probably already writing tests, but that they delete their work just after creation.
Example: During the development of a function you'll have a page/testscript in with an echo or var_dump() the result. After a manual validation of the result you'll modify the parameters of the function and check again.
With some extra effort these tests could be automated in a UnitTest. And which programmer doesn't like to automate stuff?
As for the team question as well as universal ideas about software development and testing, I would suggest Joel Spolski's website and books: http://joelonsoftware.com/ I got many insights from him.
SimpleTest - excellent documentation and explanations of testing for php
Another way to start TDD is try to use PHP framework. Without framework, it's hard to implement unit test effectively.
Related
I don't find the unit testing push in the PHP market like I see/read in the ruby/rails arena.
Could one just as easily NOT unit test in ruby/rails as in php, or is ruby just too bendable and breakable that it "more" recommended to test in ruby than in php?
Meaning there are large code bases like vBulletin, and from what I can tell, they don't unit test.
I hope you understand what I am asking here, not the pros/cons of testing, or whether one should test or not, but rather, does one language need to be tested more than another? maybe its easy to write buggy code, or break during refactoring etc.
tl;dr PHP/vBulletin/Mambo started before TDD went mainstream
PHP allows the same mistakes to be made as Ruby does. In Java/C# the compiler will complain sometimes if you do something odd at compile-time, PHP/Ruby will do that only on run-time. So if you were to compare Ruby with Java, I might have replied that I see a little more necessity to write unit-tests for PHP/Ruby. Still I consider unit-testing important no matter what the language you use.
On your findings: vBulletin (v3 development started in Dec 2002) and Mambo is nearly as old as jUnit (2000). Unit-testing (according what I can find) had its rise around the year 2000. SimpleTest/PHPUnit emerged in 2003/2004. So the devs of Mambo/vBulletin didn't use TDD back then. The structure of the written code won't have made it easy to add tests later on.
Not to dishonor any PHP developers, PHP was pretty overrun by script-kiddies, pseudo-programmers, and beginners (me included). Everybody started from scratch, wrote his/her own CMS. The reference app were some snippets found around the web. I assume that a large chunk of the PHP dev community will never have heard of unit-testing or have understood what it's good for.
Ruby was hyped much later (approx. 2007) than PHP (approx. 2000) was. It comes bundled with a lot of philosophy ("Whats good/readable/beautiful code?", "How should coding be done?"). Writing tests is somewhat a part of this philosophy.
Most books on Ruby contain a section on unit-testing, explaining why it's good and necessary. Also Rails generates a set of (empty) tests for you automatically. You are encouraged to write tests all the time - it's hard not to.
I think you dont see as much automated unit and functional testing in PHP because the community has not embraced it - though that is changing. Its not that any language requires more or less testing its more about development methodologies and the tools the developers using that language are familiar with as well as cost of implementing something (in this case the tests).
With Rails unit and functional tests are easy. Theres a whole framework integrated for it... with scaffolding if i recall correctly. This greatly decreases the cost and knowledge level required to test an application in this fashion. Many times in PHP if you want to do this you have integrate PHPUnit, Lime, SimpleTest, etc.. yourself. With the rise for frameworks like Symfony, Zend, CI, and Cake the barriers in PHP are being lowered too assuming the development team uses a framework such as these.
Ruby is no more bendable, or breakable, than other languages because a programmer is free to do stupid things in Ruby just as they are in PHP, Java, or C.
Some programming environments (IDEs) do precompile-runs and check for syntax errors in the code, but if the developer has cast things wrong, or turned off warnings or error notices, they'll still be in a position to shoot their foot off. It's not the language's fault they did stupid things. It was a lack of discipline, or experience or forethought on the developer's part, not the language, that led to the code that caused the problem.
When I wrote in C I enabled all errors and set warnings to their highest severity. My code compiled without errors and I had a high degree of confidence that the code was good. At the same time I checked all my memory-allocations to make sure I got a value back, checked my return codes from system calls, etc., because I cared that my code ran right and was clean. I'd receive code from people who turned off warnings because they didn't like the stream of messages and it would fail, and reviewing the code showed it was full of ignored return codes and didn't check memory allocations. Similar to what Forest Gump said, "Sloppy is as sloppy does."
I've worked closely with some very talented PHP developers, and their code was every bit as clean as mine or a good developer in any language. I've also worked with very talented and experienced developers who wrote garbage, again, because they didn't care to write code that was maintainable and safe.
So, while some might want to point a finger and say a particular language isn't as good as another because the language fails too often, it comes down to the person with their hands on the keyboard. Leave the language out of it.
Testing, whether it's unit or integration, or whatever, is just one more step in the programming process that helps ensure good quality. Testing seems to require 2x the code as you'd have if you didn't test, but the automated component of testing is an incredible safety-net that can't be appreciated until you've had it catch errors after code changes, that would have broken an app badly.
About six months ago I started working regularly with some code written by a non-programmer. He's very talented at what he does but he needed a senior developer to team-program with him and show him why things are done a certain way. One of the first things I did with him was introduce him to the testing safety-net. He had some test code for incidental things but nothing that tested the actual behavior of the program. Once he saw it in action he was a believer, and now writes his tests as he goes. It's an awesome thing to see. :-)
I don't think there is such a thing that one language requires more testing then the other ( they all require testing , writen tests or human tests or customer tests , all software get's tested at some point , tough it should get tested before hitting the market ).
It's not so much that ruby requires it so much as it supports it so much better, and is part of the general philosophy and best practices that surround ruby, whereas php quickly got overrun by a lot of, well, amateurs.
For web development ,
Can u send some sample test case xls report ,
Or is there any good open source plz refer ,
Is there any free automated testing for php web development ,
Thanks
Automated testing tools for PHP:
phpunit for unit tests.
Selenium is a browser-based automated testing tool which can work with any language, but includes the ability to run with phpunit.
Nobody can give you test cases for your web site since every project/application/website is unique and deserves their own unique test cases. There is no "right" or "wrong" in testing. Testing is an art and what you should choose and how well it works out for you depends a lot from project to project and your experience.
But as a professional Test Expert my suggestion is that you have a healthy mix of automated and manual testing.
(Examples below are in PHP but you can easily find the correct examples for what ever langauge/framework you are using)
AUTOMATED TESTING
Unit Testing
Use PHPUnit to test your classes, functions and interaction between them.
http://phpunit.sourceforge.net/
Automated Functional Testing
If it's possible you should automate a lot of the functional testing. Some frame works have functional testing built into them. Otherwise you have to use a tool for it. If you are developing web sites/applications you might want to look at Selenium.
http://www.webinade.com/web-development/functional-testing-in-php-using-selenium-ide
Continuous Integration
Use CI to make sure all your automated tests run every time someone in your team makes a commit to the project.
http://martinfowler.com/articles/continuousIntegration.html
MANUAL TESTING
As much as I love automated testing it is, IMHO, not a substitute for manual testing. The main reason being that an automated can only do what it is told and only verify what it has been informed to view as pass/fail. A human can use it's intelligence to find faults and raise questions that appear while testing something else.
Exploratory Testing
ET is a very low cost and effective way to find defects in a project. It take advantage of the intelligence of a human being and a teaches the testers/developers more about the project than any other testing technique i know of. Doing an ET session aimed at every feature deployed in the test environment is not only an effective way to find problems fast, but also a good way to learn and fun!
http://www.satisfice.com/articles/et-article.pdf
This answer is (almost) identical to one that I gave to another question. Check out that question since it had some other good answers that might help you.
How can we decide which testing method can be used?
I'm in charge of at least one large body of existing PHP code, that desperately needs tests, and as well I need some method of checking the production site for errors.
I've been working with PHP for many years, but am unfortunately new to testing. (Sorry!).
While writing tests for code that has predictable outcomes seems easy enough, I'm having trouble wrapping my head around just how I can test the live site, to ensure proper output.
I know that in a test environment, I could set up the database in a known state... but are there proper methods or techniques for testing a live site? Where should I begin?
[I am aware of PHPUnit and SimpleTest, but haven't chosen one over the other yet]
Unit testing frameworks like PHPUnit are built more for testing the functionality of separate, logical units (i.e. classes), not so much the behaviour of entire live sites. One household name for that is Selenium, a web application testing system. It is my understanding that Selenium tests can in turn be integrated with PHPUnit.
As for the choice between Simpletest and PHPUnit, check out my recent question about PHPUnit vs. SimpleTest - the answers to that question, notably #Gordon's, managed to convince me of PHPUnit.
I second Pekka's suggestion. Also, I strongly suggest using PHPUnit, as it is the de-facto Standard in UnitTesting frameworks in the PHP World.
Another thing you can do is head over to phpqatools.org (edit: this website is no longer active) and use the given tools to analyze your codebase, find dead code, copy and paste, code violations, etc.
Also profile your code with XDebug or Zend Debugger to find out what it is actually running how often. This way you will not only get an idea of which code you should test first (those that runs most often), but also how it performs, which is a good starting point when you wil optimize it after you have written the Unit-Tests.
In addition, check out:
Legacy Code Nightmare and
Theory and practice – migrating your legacy code
PHPUnit Manual
Till now I've been testing my web (usually written in PHP) as well as desktop applications (normally Java or C#) manually. Now I read somewhere on the net about automated tests. I tried searching to know about it in details but almost all searches end up at things like PHPUnit. Could someone please put some light on the theory behind automated tests? How a software can be tested automatically? Any limitations etc? Or may be you can tell me a place where I can read about this.
Regards
For testing the correctness of code you can use unit testing. This was first explained to me from Dive Into Python: Unit Testing and will do much more justice to the topic then I could here. Now that you know about the term unit testing, you shouldn't be far from other existing explanations that will make sense to you, be it that one doesn't.
You may find test-driven development of interest too.
Your code is not magically tested for you, as you may had the idea of. The code to test your application will be written by you. What packages like PHPUnit offer you is a framework in which you can implement your tests. These packages will provide many conveniences for defining your tests, running them together as a suite, and generating a report. These are the only automated aspects.
These Test Tools are used in the following manner as, If suppose we have to test a webform we will pas the input data into the fields they have provided us with the tool, and the number of users needs to filling the form (their user-name), In this way when this is executed then the form gets filled with provided data with individual usernames, This execution may provide u test data as performance, time of execution and load etc...
WebLoad Testing Tutorial
see the above link for load testing...
See these links as well
Functional testing
Security Testing
Link and HTML tool Testing
Performance Testing
I am a web-developer working in PHP. I have some limited experience with using Test Driven Development in C# desktop applications. In that case we used nUnit for the unit testing framework.
I would like to start using TDD in new projects but I'm really not sure where to begin.
What recommendations do you have for a PHP-based unit testing framework and what are some good resources for someone who is pretty new to the TDD concept?
I've used both PHPUnit & SimpleTest and I found SimpleTest to be easier to use.
As far as TDD goes, I haven't had much luck with it in the purest sense. I think that's mainly a time/discipline issue on my part though.
Adding tests after the fact has been somewhat useful but my favorite things to do is use write SimpleTest tests that test for specific bugs that I have to fix. That makes it very easy to verify that things are actually fixed and stay fixed.
I highly recommend Test-Driven Development by Kent Beck (ISBN-10: 0321146530). It wasn't written specifically for PHP, but the concepts are there and should be easily translatable to PHP.
PHPUnit is a standard, but it's sometimes also overwhelming, so if you find it too complex, check out phpt to get you started. It's very, very easy to write tests in it. A no brainer for any programmer.
And to answer your TDD question - I am not sure if TDD is widley used in the PHP space. I can see that rapid application development and TDD somewhat clash (strictly IMHO). TDD requires you to have the complete picture of what you build and you write your tests up front and then implement the code to make the test pass.
So for example what we do instead, is to write a lot of tests when we are done. This is not always the best approach because you sometimes end up with bogus tests that pass, but are not really useful but at least it's something you can expand on. Internally we continue on tests and basically write a test for each bug we find. This is how it becomes more solid.
I personally prefer SimpleTest. There is a command line test runner and web-based test runner, and there is even an Eclipse plugin to let you run unit tests from the IDE itself. I found the Zend to PHPUnit connection much harder to get working, especially with the debugger.
The way we use SimpleTest in-house is with a continuous integration script that we wrote ourselves. Every time we check in a feature to SVN we include the unit tests. Every hour or so, the CI script runs and calls a command line PHP script that runs all of our unit tests. If any break, I get an email. It's been a great way to reduce bugs in our systems.
However, you can just as easily use something like Phing to run your tests automatically, either on a cron job or with an SVN check-in hook.
In fact, if you want to contact me directly for further help, you can get to me through my profile info on SO. I'd love to help you out.
SimpleTest is a great system. I started out with it about 5 months ago, having never heard of TDD, and SimpleTest is easy to learn but still powerful. As for resources, I'm currently reading TDD By Example by Kent Beck, and it's good.
You should look into PHPUnit, it looks pretty much like nUnit.
Another modern tool you should look it is Codeception. It is much simplier then PHPUnit and incorporates scenario-driven approach, which is quite useful for generating documentation from tests.
Test driven development is an approach where tests are always written before code.
You should learn to PHPUNIT first in order to start TDD Development. Then while making your function you should always think how function can fail and write test case in phpunit and in the end you should write code in order to pass your test. Its will be a new approach so it will be little difficult in the beginning but once you get use to it, you will find it very useful specially for after development bugs and coding style. You can go through this Step By Step guide for understanding this concept.
Always Remember if test are written after development they are useless. So TDD is must if you are thinking to write unit tesst