Formato YAML del motore di test di Power Apps (anteprima)

Annotazioni

Le funzionalità di anteprima non sono destinate ad essere utilizzate per la produzione e sono soggette a restrizioni. Queste funzionalità sono disponibili prima di una versione ufficiale in modo che i clienti possano ottenere l'accesso anticipato e fornire commenti e suggerimenti.

I test vengono definiti in YAML seguendo le stesse linee guida di Power Fx. Altre informazioni sulla grammatica della formula YAML di Power Fx.

Visualizzare la cartella PowerApps-TestEngine/samples per esempi dettagliati.

Definizioni di schema YAML

Proprietà	Description
testSuite	Definisce un gruppo di test, i test case nel gruppo di test e la configurazione specifici del gruppo di test
testSettings	Definisce le impostazioni per il gruppo di test riutilizzato in più test case
environmentVariables	Definisce le variabili che potrebbero cambiare potenzialmente man mano che l'app viene convertita in ambienti diversi

testSuite

Usato per definire un test.

Proprietà	TIPO	Description
`persona`	corda	Obbligatorio. Utente connesso per eseguire il test. Deve corrispondere a un utente elencato nella sezione Utenti .
`testCases`	TestCases	Obbligatorio. Definisce i test case nel gruppo di test. I test case contenuti nei gruppi di test vengono eseguiti in sequenza. Lo stato dell'app viene salvato in modo permanente in tutti i test case in un gruppo di prodotti.
`testSuiteName`	corda	Obbligatorio. Nome del gruppo di test.
`appLogicalName`	corda	Optional. Nome logico dell'app da avviare. Può essere ottenuto dalla soluzione. Per le app canvas, è necessario aggiungerlo a una soluzione per ottenerla. Vedere Come identificare l'applicazione nel piano di test
`appId`	GUID	Optional. ID dell'app da avviare. Obbligatorio e usato solo quando `appLogicalName` non è presente. L'ID app deve essere usato solo per le app canvas che non si trovano nella soluzione. Vedere Come identificare l'applicazione nel piano di test
`networkRequestMocks`	NetworkRequestMocks	Optional. Definisce le simulazioni delle richieste di rete necessarie per il test.
`onTestCaseComplete`	corda	Optional. Definisce i passaggi che devono essere attivati per ogni test case in un gruppo al termine dell'esecuzione del case.
`onTestCaseStart`	corda	Optional. Definisce i passaggi che devono essere attivati per ogni test case in un gruppo prima che il case inizi l'esecuzione.
`onTestSuiteComplete`	corda	Optional. Definisce i passaggi che devono essere attivati al termine dell'esecuzione della suite.
`testSuiteDescription`	corda	Optional. Altre informazioni descrivono le operazioni del gruppo di test.

Come identificare l'applicazione nel piano di test

È necessario impostare appLogicalName o appId per identificare l'applicazione. L'uso dipende dal fatto che l'app sia definita all'interno di una soluzione.

App basate su soluzioni (scelta consigliata)

Quando si definiscono le app all'interno delle soluzioni, i test rimangono portabili in ambienti diversi. Impostare la appLogicalName proprietà per indicare che l'app è basata sulla soluzione.

Per individuare il nome logico dell'app:

Aprire la soluzione contenente l'app in Power Apps
Utilizzare il nome (non il nome visualizzato) nell'elenco. Il valore name include il prefisso di personalizzazione per il server di pubblicazione della soluzione.

App autonome

Quando l'app non è definita all'interno di una soluzione, è necessario usare la appId proprietà .

Per individuare l'ID dell'app:

Individuare l'app nell'elenco di Power Apps
Aprire Dettagli e prendere nota del GUID dell'ID app

NetworkRequestMocks

Proprietà	TIPO	Description
`requestURL`	corda	Obbligatorio. URL della richiesta che ottiene una risposta fittizia. I modelli GLOB vengono accettati
`responseDataFile`	corda	Obbligatorio. Un file di testo con il contenuto della risposta fittizia. Tutto il testo in questo file viene letto come risposta
`headers`	elenco	Optional. Elenco di campi di intestazione nella richiesta nel formato [fieldName: fieldValue]
`method`	corda	Optional. Metodo della richiesta (GET, POST e così via)
`requestBodyFile`	corda	Optional. File di testo con il corpo della richiesta. Tutto il testo in questo file viene letto come corpo della richiesta

Per le proprietà facoltative, se non viene specificato alcun valore, il routing si applica a tutti. Ad esempio, se method è Null, viene restituita la risposta fittizia indipendentemente dal metodo, purché tutte le altre proprietà corrispondano.

Per le app requestURL Sharepoint/Dataverse/Connector e method può essere uguale per tutte le richieste. x-ms-request-method e x-ms-request-url nelle intestazioni potrebbero essere configurati in tal caso per identificare richieste diverse.

TestCases

Proprietà	TIPO	Description
`testCaseName`	corda	Obbligatorio. Nome del test case utilizzato per segnalare l'esito positivo e negativo
`testSteps`	TestSteps	Obbligatorio. Set di funzioni Power Fx che descrivono i passaggi necessari per eseguire il test case. Vedere Esempio di TestSteps
`testCaseDescription`	NO	Optional. Informazioni aggiuntive descrivono le operazioni del test case

TestSteps

TestSteps può usare qualsiasi funzione Power Fx del motore di test esistente o funzioni di test specifiche definite da questo framework.
Il valore deve iniziare con un simbolo di pipe (|) per consentire le espressioni YAML multilinea seguite da un segno uguale (=) per indicare che si tratta di un'espressione Power Fx
Le funzioni devono essere separate da un punto e virgola (;).
I commenti possono essere usati e devono iniziare con caratteri barra rovesciata doppia (//).

Esempio di TestSteps

testCases:
   - testCaseName: Fill in a city name and do the search
   testSteps: |
      = Screenshot("connectorapp_loaded.png");
         SetProperty(TextInput1.Text, "Atlanta");
         Select(Button1);
         Assert(Label4.Text = "You are seeing the mock response", "Validate the output is from the mock");
         Screenshot("connectorapp_end.png");

testSettings

Consente di definire le impostazioni per i test nel piano di test.

Proprietà	TIPO	Description
`browserConfigurations`	BrowserConfiguration[]	Obbligatorio. Elenco delle configurazioni del browser da testare. È necessario specificare almeno un browser.
`extensionModules`	extensionModules	Optional. Contiene dati sulle estensioni da abilitare.
`filePath`	corda	Optional. Percorso del file in un file yaml separato con tutte le impostazioni di test. Se specificato, eseguirà l'override di tutte le impostazioni di test nel piano di test.
`headless`	boolean	Optional. Il valore predefinito è vero. Se impostato su false, il browser viene visualizzato durante l'esecuzione del test.
`locale`	corda	Optional. Sintassi delle impostazioni locali/impostazioni cultura in cui vengono scritti i test case o i passaggi di test. Se non specificato, `CultureInfo.CurrentCulture` viene usato per le impostazioni locali per impostazione predefinita per l'analisi dei passaggi di test. Vedere Considerazioni relative all'area geografica e alla lingua
`recordVideo`	boolean	Optional. Il valore predefinito è false. Se impostato su true, viene acquisita una registrazione video del test.
`timeout`	numero intero	Optional. Valore di timeout in millisecondi. Il valore predefinito è 30.000 millisecondi (30 secondi). Se un'operazione richiede più tempo del limite di timeout, termina il test in un errore.
`powerFxTestTypes`	`name` `value` paio	Optional. Elenco di nomi di tipo e definizioni di tipo Power Fx. Vedere l'esempio di powerFxTestTypes
`testFunctions`	`description` `code` paio	Optional. Elenco di definizioni di descrizione e di funzioni Di Power Fx. Vedere l'esempio testFunctions

extensionModules

Contiene dati sulle estensioni da abilitare.

Proprietà	TIPO	Description
`enable`	bool	Indica se i moduli di estensione sono abilitati o meno.
`allowPowerFxNamespaces`	list	Elenco degli spazi dei nomi di PowerFx da abilitare.
`parameters`	coppie chiave-valore	Proprietà con valori per controllare i moduli di estensione. Al momento, solo il parametro booleano `enableDataverseFunctions` è valido per questo.

Questo esempio illustra come abilitare lo spazio dei nomi PowerFx Preview :

testSettings:
  extensionModules:
    enable: true
    allowPowerFxNamespaces:
    - Preview

Altre informazioni sulle funzioni di anteprima

Considerazioni relative all'area geografica e alla lingua

Il motore di test supporta varie impostazioni della lingua e dell'area, ad esempio separatori decimali ed elenchi. La testSettings.locale proprietà controlla questi comportamenti. Per altre informazioni, vedere Supporto globale in Microsoft Power Fx.

Esaminare queste configurazioni di esempio nel repository GitHubPowerApps-TestEngine:

Esempio di powerFxTestTypes

powerFxTestTypes:
 - name: ControlName
   value: |
      {ControlName: Text} 
 - name: Options
   value: |
      [{Name: Text, Value: Number}]

Questo esempio illustra come definire tipi Power Fx personalizzati da usare nei test case. Il ControlName tipo è definito come record con un singolo Text campo, mentre il Options tipo è definito come tabella di record, ognuno contenente un Name campo di tipo e un Text campo di tipo ValueNumber. I tipi personalizzati possono essere usati per creare scenari di test più complessi e specifici, migliorando la flessibilità e la potenza delle definizioni di test.

Esempio di testFunctions

testFunctions:
 - description: Wait until control is visible using Document Object Model (DOM) selector
   code: |
    WaitUntilVisible(control: Text): Void = 
      Preview.PlaywrightAction(Concatenate("//div[@data-id='", control, "']"), "wait");
 - description: Get the options for a control using Power Fx control from Model Driven App (MDA)
   code: |
    GetOptions(control: ControlName): Options =
      Preview.GetOptions(control);

Questi esempi di funzioni di test illustrano come definire funzioni Power Fx personalizzate da usare nei test case. La WaitUntilVisible funzione usa un selettore DOM per attendere fino a quando un controllo specificato non è visibile, usando le azioni Playwright. La funzione GetOptions recupera le opzioni per un controllo specificato da un'app basata su modello (MDA), utilizzando il controllo Power Fx. Queste funzioni personalizzate migliorano la flessibilità e la potenza delle definizioni di test, consentendo scenari di test più complessi e specifici.

BrowserConfiguration

Ogni testSettings richiede almeno un BrowserConfigurationoggetto .

Proprietà	TIPO	Description
`browser`	corda	Obbligatorio. Browser da avviare durante il test. Deve corrispondere ai browser supportati da Playwright.
`device`	corda	Optional. Dispositivo da emulare all'avvio del browser. Deve corrispondere ai dispositivi supportati da Playwright
`screenHeight`	numero intero	Optional. Altezza dello schermo da usare durante l'avvio del browser. Se specificato, `screenWidth` è necessario specificare anche .
`screenWidth`	numero intero	Optional. Larghezza dello schermo da usare durante l'avvio del browser. Se specificato, `screenHeight` è necessario specificare anche .

environmentVariables

È possibile archiviare diversi tipi di valori come valori ambientali, ma il caso più comune consiste nell'archiviare le informazioni sulle credenziali con un elenco di utenti.

users

Per assicurarsi che le credenziali vengano archiviate in modo sicuro, la definizione di test fa riferimento agli utenti che usano .personaName L'archiviazione delle credenziali nei file del piano di test non è supportata.

Esempio:

environmentVariables:
    - users:
        - personaName: "User1"
          emailKey: "user1Email"
        - personaName: "User2"
          emailKey: "user2Email"

Viene personaName usato come parte della definizione di test per indicare l'utente a cui eseguire il test.

Meccanismi di archiviazione delle credenziali supportati

Per archiviare le credenziali come variabili di ambiente, è possibile impostarle come segue:

# In PowerShell - replace variableName and variableValue with the correct values
$env:variableName = "variableValue"

In YAML è necessario definire due proprietà per indicare che le credenziali di questo utente vengono archiviate nelle variabili di ambiente:

emailKey: variabile di ambiente usata per archiviare il messaggio di posta elettronica dell'utente.

YaML di esempio:

    - personaName: "User1"
      emailKey: "user1Email"

Esempio di PowerShell per impostare le credenziali utente in base a YAML:

$env:user1Email = "someone@example.com"

Vedere anche

Panoramica del motore di test di Power Apps (anteprima)
Funzioni Power Fx del motore di test di Power Apps (anteprima)

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2025-10-04