Follow Us:
Let's face it. Salesforce.com and Force.com are new kids on the block. They're growing up fast, and establishing their territory, but they've still got some maturing. Most languages these days have an interactive debugger. However, APEX is the exception. If you're new to APEX coding, I recommend you take a look at three things to help you overcome this hurdle: 1) Debug Logs, 2) Running tests in Eclipse, 3) Running tests in Salesforce.com.
Since there is no interactive debugging with APEX, you've got to find ways to identify how far your code ran and what it did when it got there. One thing I do while writing code is to add debug logs to indicate the values I'm testing and to tell me that things ran up to that point. If you write good test methods, you should know what to expect at each point in your code.
system.debug("checking value: " + myvar);
When the debugger passes this point, a statement is logged with the value and if it's not what I expected, then I know where to start digging. It takes a little more effort during development, but pays big dividends when testing and even bigger dividends when you run into production problems.
One thing that can be a total pain is writing your code in Eclipse and then deploying it to the server each time you're ready for testing. If your development style has you writing small blocks of code and then testing, you're going to spend a lot of time deploying the solution. One short cut if working in a development environment is to simply "Save" the code to the server rather than deploy it. This can save time, but it's still time consuming.
Once you've got your code on the server, it's pretty straightforward to run the test code or to do run through some test scenarios. After you run the test you can then click on the code coverage percentage where you'll be able to see your code coverage in blue (covered) and red (not covered). Still, this can take a lot of time redeploying.
Perhaps a better way is to go to Eclipse, right click on the Classes folder, and pick "Force.com->Run Tests". This will run all the tests for your classes and return the code coverage to Eclipse in a list. It's a lot faster and easier than going back and forth between the application.
Once you pass all of your test cases and the code runs into a problem in production, you'll want to turn on the debug log to see where things go. If you've done a good job with debug log statements in code, the debug session should go very quickly. If not, you'll be scratching you head and having to do a lot of interative deployments to figure out where things went wrong and sometimes this can be difficult to recreate in complex implementations on a development environment.
Adding debug logs, using the testing on the server and eclipse has saved me a lot of development time, and I hope it works equally well for you.
The complementary paper includes over 12 years of research, recent survey results, and CRM turnaround success stories.
Request Download
This 60-second assessment is designed to evaluate your organization's collaboration readiness.
Learn how you rank compared to organizations typically in years 1 to 5 of implementation - and which areas to focus on to improve.
This is a sandbox solution which can be activated per site collection to allow you to easily collect feedback from users into a custom Feedback list.
Whether you are upgrading to SharePoint Online, 2010, 2013 or the latest 2016, this checklist contains everything you need to know for a successful transition.