Basically I'm wondering if anyone has any tips for ensuring your code is well tested without getting any help from anyone else in a limited time frame?
In the past I've always been able to find someone else to do testing on my code or had a dedicated quality assurance team go over everything and find all the errors.
I'm usually pretty careful but I always find there a things I miss and when I test them I just don't see them.
However in my current job I've been given two PHP web applications to write in a very limited time frame and I've been told I need to do all the testing myself despite my feedback that this wasn't a good idea.
I was wondering if anyone else had this problem before and could offer some insight?
I was thinking perhaps it would be good to write a quick test plan before coding each area and also to double check the requirements before doing testing.
Certainly unit testing, whether test-first or not, should be your first line of defense, ensuring that each piece of your application works the way you think it should. However, the type of testing you're talking about, where it can be helpful to get another pair of eyes, is more in the area of acceptance tests -- does the application as a whole work the way it should; does it work for various weird scenarios or behaviors, etc.
One helpful approach is to imagine personas: first test the application as yourself, but then test it again imagining that you are 85 years old, can't see terribly well, and don't use a mouse that well. You may tend to click on the brightest or largest thing, assuming it's what you're supposed to do, which it may not be. Now imagine you're 12 and in a tearing hurry. No way are you going to read instructions. Does it still work?
For any given field, what are the edge cases of what a person might type in? What happens if you type only spaces? Only numbers into a textual field? What happens if you type HTML? Javascript? Something in a non-western alphabet? What if you type something really really long?
The key is not just to test the "happy path", where the user goes through the application the way you had in mind. Go through the application in ways no one ever should. Because... they will.
The other important piece is never to ignore anything. It's easy to have a weird screen come up and say to yourself "Oh, that's just a fluke." You have to make yourself notice and track down everything that isn't just as it should be.
There are always constraints on how much testing you can do. Within the constraints, you obviously need to construct tests. Clearly you want to construct tests for the most critical areas first (security, possibility of damage, loss of data, functionality).
Other than the functional specification, you're not likely to get a lot of manual help deciding what to test. But you can get automated help in the form of test coverage tools. These tools tell you what code you have tested, and therefore what code you have NOT tested. By inspecting the untested code, you can determine if it is more or less critical, and therefore more or less deserving of having tests coded for it before release. Test coverage tools also tell you the ratio of tested code versus total code, and its an industry best practice to ensure that this ratio is 70% or above. You can use this data to negotiate more time with your boss by a simple artifice: "We only have 15% test coverage... dare we release it?"
A test coverage tool that works with PHP can be found here: Semantic Designs PHP Test Coverage Tool
I think TDD is exactly what you're looking for. First write tests, then write the code that passes the tests. You don't need anyone else apart from you (some help with the tests would be recommended, though) and you'll have a clearer idea of what the tool should do, even before start coding on it.
Your employer clearly doesn't think that testing is important. You should quit and find a proper job.
I hate to say it, but I think in your case Alex Tingle's right. It's an impossible situation.
JacobM and Santi are correct in mentioning unit testing, acceptance testing, and test-driven development. I'd add code coverage and static analysis tools to that list.
But while TDD or basic unit testing will generally pay off in decreased testing time, lowered defect rates, and ease of maintenance, they won't help you deliver on time in a deathmarch. This is especially true if you aren't experienced at writing automated tests.
Politely phrased, your boss is asking you to incur technical debt. Correctly phrased, he's asking you to disregard professional ethics.
Smile, say "yes sir," do the best you can in the time allotted, and update your resume.
One thing to bear in mind is that there's a natural tendency for a developer to test the "best path" for their code. In other words, you wrote it, so you know that you're supposed to click on certain spots, type in certain things, and so you test for that. This is, of course, important.
There are some good suggestions here, but the one that seems to be missed by most (but not all) is negative testing. Basically, you need to test the boundaries and you need to test the malicious. As noted, put script code in fields such as:
<script>alert('abc')</script>
It becomes pretty obvious that you failed to encode properly if you get an alert! Another thing to do is:
abc' or 'a' = 'a'
That will potentially show SQL injection problems in things like authentication. You can also test SQL injection with things like:
abc'; drop table users; select * from dual where 'a' = '
If your table just went away, you have an issue! There are a huge number of examples, but at the very least you need to spend some time testing the OWASP top 10.
Other places where you want to test is things like very large numbers, especially when expecting integer input on a 32 bit platform, negative values, no values, etc. Basically, test that the desired flows work and then do everything you can to break it.
I agree with the previous answer posted on the value and effectiveness of Test Driven Development and Unit Testing. If done correctly, a TDD process in which you write your unit tests before you write the production/deliverable code will help maintain your focus and help validate your design and interfaces. Additionally, other developers will be able to have a clear and consistent way to work from on how to use and consume your code in a very straight forward manner. Just keep in mind that Unit Testing is not the same and is not a substitute for full integration testing. In this approach, you may still need to write a full integration test plan.
I work primarliy in .NET, and have had nothing but good results in working with NUnit.
I haven't worked in PHP before, but from what I've seen, you may want to consider SimpleTest or PHPUnit.
Given your boss's requirements, which you have to respect while you work for him and up until you can change his mind, you have given the correct answer in the question.
来源：https://stackoverflow.com/questions/1484687/self-testing-tips