Direkt zum Hauptbereich

Winter 14: Code Coverage wegoptimiert?

Offensichtlich war die gesamte für die Qualitätskontrolle zuständige Mannschaft von Salesforce im Urlaub als das neue Winter 14 Release fertiggestellt wurde.

Beim Testen einer Klasse stellte ich fest, dass die "Code Coverage" Spalte fehlt.


Die einzige Möglichkeit, sich einen Überblick über die Testabdeckung zu verschaffen, bietet die Developer Console.


Hilft aber auch nur bedingt, da die Übersicht der nicht getesteten Zeilen fehlt.
Labels:

Kommentare

  1. Anonym11. September 2013 um 16:24

    Ist mir heute auch aufgefallen - ärgerlich

    AntwortenLöschen
  2. Anonym26. September 2013 um 10:58

    Für die Dev.Console gibt es ein gutes Webinar: http://www.youtube.com/watch?v=I8EtxMLfFDQ
    Mit wenigen Klicks die Klasse öffnen und die Zeilen werden, wie man es kennt, angezeigt. Ich denke, dies ist Absicht. Als eine Art Fingerzeig, dass du Entwickler doch bitte mehr Wert auf gute Testklassen, Performance, etc legst :)

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Salesforce APEX Techniken

Mal auf die Schnelle zusammenbasteln „Das kann doch nicht so schwer sein!“ Das ist vermutlich einer der berühmtesten Sätze, mit dem ein (Salesforce) Entwickler konfrontiert wird.  Diese Aussage wird vor allem als Waffe benutzt, um den vom Entwickler geschätzten Aufwand und die damit verbundenen Kosten zu reduzieren. Ein mutiger "Angreifer" mit wenig Entwicklungs- und Prozess-Know-how ergreift nicht zu selten die Initiative und stellt selbst triumphierend das Produkt seiner Wünsche her. Es ist in der Tat nicht schwer, schnell das gewünschte Ergebnis zum Beispiel in Form eines Triggers zu erzielen. Im Internet kursieren viele Beispiele dazu. Die mächtige Salesforce Community unterstützt im Problemfall. Einige Lösungen aus dieser Kategorie durfte ich in den letzten Jahren begutachten. Sie alle haben eine Gemeinsamkeit: sie funktionieren nicht (lange)! Da fühlt man sich manchmal wie die Stiftung Warentest, die ein chinesisches Billigprodukt testet. Ziel als Ausgangspunkt
Kommentar veröffentlichen
Mehr anzeigen

Crazy SOQL

Genauso habe ich heute geschaut, als ich den folgenden Code ausgeführt und das Ergebnis ausgewertet habe: CustomObj__c obj = [select LookupField__c from CustomObj__c where LookupField__c != NULL AND Id = 'hereisavalidid']; system.debug(' LookupField__c darf nicht NULL sein '); if(obj.LookupField__c == null){     system.debug(' Also doch NULL '); } Und was sehen meine müde Augen im Log... LookupField__c ist ein Lookup- und Pflichtfeld, somit darf eigentlich per Definition nicht NULL sein. Offensichtlich gibt es (alte) Daten im System mit dem  LookupField__c = NULL Habe erwartet, dass die SOQL Abfrage die NULL-Daten filtert.
Kommentar veröffentlichen
Mehr anzeigen

Bad value for restricted picklist field

Der Einsatz von "Restricted Picklists" bereitet spätestens im Deployment Kopfschmerzen. Basiert das Deployment auf Basis eines Drittanbietertools, dann sind die Kopfschmerzen noch intensiver. In meinem Fall habe ich versucht, ein neues Picklist-Feld mit Copado zu deployen. Während der Bereitstellung bekomme ich die folgende Fehlermeldung: System.DmlException: Insert failed. First exception on row 0; first error: INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST, bad value for restricted picklist field: Z012: [CountryGroup__c] Das neue Picklist-Feld übernimmt alle Werte aus einem Global Value Set. Das bedeutet, die Option "Restrict to the values defined in the value set" ist automatisch aktiv und lässt sich nicht deaktivieren. Eine APEX-Testklasse beschreibt ebenfalls die neue Pickliste. Mit dem folgenden Workaround konnte ich das Deployment-Problem lösen: 1) Global Value Set samt Pickliste per Changeset in die Zielorg übertragen und bereitstellen ggf. Prof
Kommentar veröffentlichen
Mehr anzeigen