I found a similar answer here:
How to unit test works in salesforce?
But those didn't really seem to answer my particular question.
I "stubbed out" some test classes. We should have been doing this from the beginning, but they handed a group of developers a SalesForce project who have never done SalesForce before...then put us on a time crunch. They told us at the time not to worry about unit testing, and now we find out that SalesForce requires 75% or greater code coverage in order to be in production.
Anyway, I know I can test for state in methods that return void, and I know I can test the return type of methods that have them.
But my question is: How do I test values that are supposed to be input through a VisualForce page? Do I just create the class and fill in the info?
I'm much more familiar with Unit Testing in C#, to the point where I use Roy Osherove's test method naming convention, or at least my version of it.
Additionally, how would I test pages that have a querystring? I'm assuming I would do a PageReference with some kind of query string, but unit tests, in general, should run independently.
My main concern is running the tests dynamically (i.e. dynamic record IDs), and what happens if there are no records (i.e. if the dev/testing environment get wiped).
So, thoughts on this?
You don't test the Visualforce page, you test the controller. You can create an instance of your controller in the test, feed it the data you need (parameters) and directly call the methods in the controller.
MyPageController ctrl = new MyPageController(params)
ctrl.loadData();
ctrl.saveInput();
ctrl.alertUser();
It is best practice to use a testUtils class that ceates dummy data for your tests. Then just call the appropriate methods from your test class.
List<Contact> contacts = testUtils.createContacts();
insert contacts;
Any trigger that works on insert will be fired, and you get your code coverage. And so on.