La taverne du testeur

Principes SOLID simplifiés (1/5): Responsabilité unique

Les principes S.O.L.I.D dans un contexte d’automatisation des tests

L’acronyme S.O.L.I.D a été inventé par Michael Feathers à partir des principes de programmation orientée objet identifiés par Robert Cecil Martin, Ces principes visent à rendre le code plus lisible, facile à maintenir, extensible, réutilisable et sans répétition.

L’automatisation des tests c’est un vrai projet de développement et lorsque les principes S.O.L.I.D ne sont pas appliqués le code devient difficile à maintenir ou à faire évoluer.

Dans cet article, je vous propose une explication du principe Responsabilité unique (Single Responsibility)

N’hésitez pas a découvrir les autres principes SOLID dans cette série d’articles:

Le principe de responsabilité unique stipule qu’une classe ne devrait avoir qu’une seule raison de changer et une seule responsabilité.

On comprend toujours mieux avec un exemple!

Un mauvais exemple:

public sealed class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    public bool Active { get; set; }

    public void ActivateCustomer()
    {
        Active = true;
    }

    public void InactivateCustomer()
    {
        Active = false;
    }

    public void AddCustomer()
    {
        // Some implementation here (database) ...
    }

    public void DeleteCustomer()
    {
        // Some implementation here (database) ...
    }
}

Le code de l’exemple est incorrect car il a deux responsabilités, les règles de gestion et la persistance de la base de données.

Un bon exemple:

public sealed class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    public bool Active { get; set; }

    public void ActivateCustomer()
    {
        Active = true;
    }
    public void InactivateCustomer()
    {
        Active = false;
    }
}
public sealed class CustomerRepository
{
    public void AddCustomer(Customer customer)
    {
        // Some implementation here (database) ...
    }

    public void DeleteCustomer(Customer customer)
    {
        // Some implementation here (database) ...
    }
}

Le code est correct car les responsabilités ont été réparties et chaque classe n’a qu’une seule raison de changer.

Si vous avez aimé cet article, n’hésitez pas à le partager !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

conférence

La JFTL 2023: quand la nouveauté rime avec engouement

La JFTL de tous les records La JFTL 2023 a pris fin mardi 13 juin après avoir proposé 1 journée de tutoriels le lundi et une journée de conférence le mardi. Cette année la fréquentation a battu des records avec plus de 250 participants aux différents tutoriels et 1300 inscrits

Lire la suite »
culture générale

[ISTQB] Les Objectifs des tests

Les tests sont très utiles et instinctifs. Nous en parlons souvent dans la taverne à travers, par exemple cet article sur le « but des tests » et celui sur « ce que nous apporte le test« . Le rôle des tests est une question universelle dans le monde du logiciel. Ce rôle est

Lire la suite »
conférence

Organiser la JFTL: le comité de programme (1/3)

Introduction L’organisation de tout événement est un travail minutieux que l’on a souvent tendance à sous-estimer la première fois que l’on est amené à participer à l’organisation d’un de ces événements. J’ai le plaisir d’avoir (et de continuer) à contribuer à l’organisation de beaux événements comme la STLS, les webinaires

Lire la suite »