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 Community URL Settings

Ich habe mich in den letzten Tagen etwas ausführlicher mit Salesforce Communities in Kombination mit der API beschäftigt. Ein Problem dabei war, den richtigen Endpoint zu berechnen, wie im letzten Beitrag beschrieben API im Salesforce Partner Portal. Um die Weichen im Code für Community Benutzer einzubauen, muss während der Laufzeit berechnet werden, in welchem Context sich der aktuell eingeloggte Benutzer befindet. Dabei muss man sich zwangsweise mit den Fragen folgender Art beschäftigen: ist der eingeloggte Benuter ein Community Benutzer? ob und welche Community ist gerade aktiv? wie sieht die definierte Community URL aus? Antwort auf die Frage 1: private Boolean isCommunityUser(){         Boolean bIsCommunityUser = false;         String sUserType = UserInfo.getUserType();         sUserType = sUserType.toUpperCase();         if(sUserType == 'STANDARD')                 bIsCommunityUser = false;         if(sUserType == 'PARTNER')                  bIsCommunity
Kommentar veröffentlichen
Mehr anzeigen

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

Zeitgesteuerter Flow blockiert Custom Leadkonvertierung

Die programmierte Konvertierung eines Leads bricht mit der Fehlermeldung "Unable to convert lead that is in use by workflow" ab. Der Grund ist ein Prozess, der automatisiert und zeitgesteuert ausgeführt wird. Dieser Prozess ruft zu einem späteren Zeitpunkt einen Flow auf. Während der Speicherung eines Leads wird dabei automatisch ein Flow Interview erstellt. Dieser Datensatz vom Typ "FlowInterview" blockiert die Leadkonvertierung. Lösung: Unmittelbar vor der Leadkonvertierung eine Checkbox auf dem Lead auf TRUE setzen. Da dieselbe Checkbox in den Process Builder Kriterien eingebunden ist und der Prozess nur auf den FALSE Wert reagiert, löscht das System automatisch das entsprechende Flow Interview.
Kommentar veröffentlichen
Mehr anzeigen