Articles in category: Italiano
Definizione:
Il principio OPEN/CLOSE fa riferimento all’acronimo SOLID. introdotto da Michael Feathers che riporta alcune buone pratiche di programmazione ad oggetti ancora di forte attualità.
OPEN/CLOSE (la O dell’acronimo), nella sua definizione più generale indica che: un modulo (un oggetto, una classe o un gruppo di funzioni) debba essere aperto alle estensioni ma chiuso alle modifiche.
Questo principio tuttavia non è altro che la formalizzazione e il raggruppamento di concetti e linee guida già presenti da tempo nella programmazione ad oggetti.
Tra i molti strumenti utili presenti in Xcode, il testing framework XCTest è certamente uno dei più rilevanti, non solo per l’importanza intrinseca dello Unit Testing in generale, ma soprattutto per la facilità con la quale è possibile scrivere ed eseguire test direttamente dall’IDE out-of-the-box, senza la necessità di installare componenti di terze parti o impostare una particolare configurazione per i progetti.
In effetti Xcode, al momento della creazione di un nuovo progetto, oltre a creare un target per il binario principale crea automaticamente anche un target di test, cioè un bundle aggiuntivo che può essere caricato nel bundle principale per poter fisicamente eseguire i test una volta avviata l’app. Nell’immagine seguente è possibile vedere come, in un progetto appena creato, sia già presente il test bundle, in questo caso chiamato AwesomeAppTests.xctest:
Le ACL (Access Control List) sono un strumento molto potente per poter definire l’accesso a risorse con una granularità molto fine. Nel quotidiano abbiamo già modo di utilizzarle per definire i permessi per accedere a file su Unix o quali pacchetti far passare attraverso un firewall o ancora l’accesso a database.
In Symfony le ACL sono disponibili out-of-the-box nel caso di installazione completa e permettono la definizione delle regole di accesso a risorse tramite ruoli e maschere. Mentre i ruoli rappresentano dei sottoinsiemi degli utenti di una data applicazione (amministratori, backoffice, business analyst) e possono essere visti come delle etichette da assegnare ad un utente, le maschere sono la rappresentazione numerica delle azioni che possono essere effettuate dagli utenti aventi determinati ruoli. Per tornare all’esempio del filesystem Unix, i ruoli possono essere Owner, Group o Others mentre le maschere sono ad esempio 7 (lettura, scrittura e esecuzione) indicato per ciascun ruolo.
Le specifiche PSR-7 descrivono una proposta di standardizzazione delle interfacce per i messaggi HTTP.
Come sappiamo, il protocollo HTTP, attraverso le specifiche redatte dal W3C, definisce una serie di regole di comunicazione che vengono implementate dalle applicazioni client e server che lo adottano.
A prima vista niente di nuovo sotto il Sole dunque, ma cerchiamo insieme di comprendere l’insieme di problematiche che sono al centro di questo nuovo dibattito che riguarda gli standard di codifica del linguaggio PHP.
Controllare il tasso di coverage dei test è un’attività frequente tra gli sviluppatori.
Numerosi sono i fattori che hanno reso il code coverage popolare:
- è una metrica facile da comprendere;
- si misura senza difficoltà;
- è oggettiva e imparziale;
- è universale (applicabile a tutti i paradigmi di programmazione).
Ma al di là di questi vantaggi, possiamo affermare che una test suite con un’alta percentuale di coverage sia realmente efficace?
Quando un test è efficace?
Una test suite è considerata efficace se consente di rilevare una grande quantità di failure; d’altronde, ciò è proprio la finalità ultima del software testing.
La massima efficacia è realizzabile solo applicando testing esaustivo ma, siccome ciò è spesso impraticabile, ci si accontenta di test più semplici con un’efficacia inferiore.
È importante notare che, a differenza del coverage, il livello d’efficacia viene stabilito soggettivamente dallo sviluppatore.
