Wow, does one of our managed-package vendors have me riled up.
I detected a bug in their code that means an "@isTest"-flagged unit test can't INSERT a new record from various tables (including "User" records of a certain type of "Profile").
In other words, I can't write unit tests that have anything to do with several of our core tables.
I reported the bug and pointed out that:
- such INSERT statements work fine against "the real database," executed in the "Execute Anonymous Window" of the Developer Console, and that
- they work fine with the "Run Test" button in "@isTest(SeeAllData=True)"-flagged unit tests (a big no-no), but that
- as soon as you wrap such an INSERT statement in a test method/class annotated simply with "@isTest," it fails against various closed-source-code triggers in their managed package.
Clearly, their triggers have some weird bugs that they never detected because they "cheated" when writing all their unit tests by adding "(SeeAllData=True)" to "@isTest" (that's the case in all the open-source work
they custom-developed for us).
Their codebase doesn't seem to be able to hold up to an empty database the way Salesforce code is supposed to, so it seems they simply make sure they're never showing it off to the customer on an empty database and have all unit tests look at "actual data" in the database.
Lovely.
So what'd they do in response to my problem?
Added "(SeeAllData=True)" to my proof-of-bug code and told me everything was all better.
*glares*
No.
It. most. definitely. is. not.
P.S. In the 29 new lines of code you "added" to my proof-of-bug unit test as well, vendor, you exposed a 2nd broken closed-source trigger when I turned off your "(SeeAllData=True)." So thanks for that, I guess -- saved me opening a 2nd ticket? *cough* #NotThatYouShouldHaveFoundItYourselfOrAnything
No comments:
Post a Comment