Greetings Guys,
I wanted to see if I can lean on a bit of the expertise here to help me solve a testing related problem I seem to be facing. Most of my employers have been small businesses that build web software. The dev teams are generally very small (2-3 guys), and the companies don't have the revenue to support a QA department. As a result, the developers are normally left to figure an approach approach to testing the product.
Existing testing practices follow a very loose set of test cases (steps to test a single feature). There's a few unit tests here and there, but as far as code coverage goes it doesn't exist. The product as it stands is probably somewhere around 35,000 lines of code. As the size of the product continues to increase, as you can imagine it becomes more difficult to test.
The app is written in PHP5. The project doesn't use any sort of MVC setup, so the page level logic is normally contained in an appropriate .php file. So for example, we might have a page that asks for an email address. The validation code for checking that email address (among other things) would reside at the top of that page. There's classes, but they don't really handle business logic and more serve as a method of getting stuff into and out from the database. The code for the mostpart is fairly clean & readable. That said, it's already to the point where the amount of testing time required to adequately make one testing pass has become too excessive.
Have any of you guys faced a similar situation? Any thoughts for solutions? My gut feeling is that time needs to be invested in getting code coverage in the form of unit tests. Given the limited financial resources, and the existing state of the product, I'm sort of at a loss. Any thoughts/suggestions welcome.
Thanks guys.
Real-World Testing Questions
Moderator: General Moderators
-
nowaydown1
- Forum Contributor
- Posts: 169
- Joined: Sun Apr 27, 2008 1:22 am
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Re: Real-World Testing Questions
It sounds like Selenium would be a good idea, since a lot of what you're doing right now is probably manual testing. However, if you don't have a "testing culture", it'll be difficult to keep the tests maintained.
Re: Real-World Testing Questions
First thing to do is to encourage your colleagues/employers to try out TDD/BDD - don't force it. It's guaranteed to be rejected if forced 
Try out Ping Pong programming, it's good fun, and you can add a degree of competitiveness to it if you think it won't cause conflict, which is a good way to keep the discipline. (e.g. add a points system, so if developer A writes one line of test, that takes developer B 10 mins to satisfy, he/she scores 10 points. Developer B writes one line that takes Developer A 5 mins to score, he/she only scores 5 points etc.)
There's some good literature on converting "legacy" applications, such as the Strangler Pattern devised by Martin Fowler and friends.
Try out Ping Pong programming, it's good fun, and you can add a degree of competitiveness to it if you think it won't cause conflict, which is a good way to keep the discipline. (e.g. add a points system, so if developer A writes one line of test, that takes developer B 10 mins to satisfy, he/she scores 10 points. Developer B writes one line that takes Developer A 5 mins to score, he/she only scores 5 points etc.)
There's some good literature on converting "legacy" applications, such as the Strangler Pattern devised by Martin Fowler and friends.
Re: Real-World Testing Questions
Bad code can be very difficult to test, so much so that it may be better just to tear it up and start from scratch. I had to do something similar recently with one of the first apps I ever wrote. It worked but it was impossible to maintain. If good code is a finely-crafted Rembrandt this was a load of old Jackson Pollocks.nowaydown1 wrote:That said, it's already to the point where the amount of testing time required to adequately make one testing pass has become too excessive.
Anyway, if it really is that bad, I think I'd start by writing acceptance tests. These will tell you when something isn't working (although not why: you need fine-grained unit tests for that). That gets the app under control. The same tests also define the target to hit for the new version. On the side I'd TDD away through the code until it's sorted.