9

I recently tried to do TDD (test driven development) on Force.com and hit a limit that seems to contradict my understanding of how Salesforce.com wants us as developers to work.

What I just did was code a little, run tests, code a little run tests. As the Eclipse IDE testing feature sucks so much for the last years, I ran my test from the browser and after an hour or so I hit a limit...

One that I did not discover before. Max amount of tests run per 24h.

TDD lives from having a lot small and fast running tests. But when I can only run them 10 times per day how much TDD is this?!

I opened a case with partner support and although the response was anything but clear, I think their idea is that we should test outside of their UI (via API) and that the limits don't apply their.

I am confused...Can you help?

Improve this question
4
  • 2
    The platform is WAY too slow to seriously do TDD, it's a fool's errand IMHO. It's alright when you're in a Java world where running a JUnit test costs 2 seconds, but Force.com is so much slower than that. The limit you hit (I haven't hit this before - how many executions did you do?) is another justification.
    – jkraybill
    Apr 12, 2013 at 1:20
  • 1
    One way to speed up tests is to not do it in production. in production tests run serially, but in sandboxes, they run in parallel. How much code are you deploying every day that you need to run so many tests every day?
    – PartOfTheOhana
    Apr 12, 2013 at 2:23
  • 1
    One point of clarification - the limit is on the total number of test classes that can be queued per a 24-hour period. It is the greater of 500 or 10 multiplied by the number of test classes in the organization. This limit applies to tests running asynchronously. This includes tests started through the Salesforce user interface including the Developer Console or by inserting ApexTestQueueItem objects using SOAP API.
    – Daniel Hoechst
    Apr 12, 2013 at 15:21
  • 1
    Well then easy fix, create a whole bunch more test classes?
    – jkraybill
    Apr 16, 2013 at 4:33

1 Answer 1

Reset to default
9

I have had mixed success with TDD on the Force.com platform. Along with what you mentioned, @jkraybill made a great point that it is way to slow to do TDD as you might have experienced it in the Java world as part of the normal development process for any sizeable project.

TDD definitely works for bug fixes. When I find a bug I do write a failing unit test (or tests) that replicates the bug, before I fix the bug. Then I see that unit test(s) pass after the bug is fixed.

We modified the Automated Unit Test Recipe by LukeJFreeland to give it the ability to recognize 'TODO' unit tests. On projects we'll write stub unit test methods such as the following before writing the code.

@isTest
static void testCalculateXyzWithValidInput() {
    System.assert(false, 'TODO: Need to implement.');
}

The modified Automated Unit Test Recipe code then reports all of the failures, but breaks out the failure counts into TODO failures and real failures. In this way we are sort of writing the tests first, but it is definitely not TDD in the way that you are thinking about it.

Improve this answer
1
  • 1
    +1 for replicating code bugs with unit tests first; I do this, but I'd consider this more "Test-Driven Maintenance" than "Test-Driven Development" :)
    – jkraybill
    Apr 16, 2013 at 4:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .