EnterpriseController testing - 22/05/2026

1. Dead code et refactor

• Le if (!$user) -> 401 present dans chacune des 6 methodes est inatteignable : le middleware auth:api du groupe renvoie deja 401 avant d’entrer dans le controller.
• Incoherence d’acces : index et store renvoient 403 pour un non-owner, mais show / update / destroy / updateStorefront n’ont aucun check de role — un non-owner (ou un owner tiers) tombe sur un 404 via le scope where('owner_id', $user->id). Comportement sûr (pas de fuite de donnees) mais reponse incoherente d’une route a l’autre.

2. Tests de chaque route — approche features-first (non-unit)

Routes du groupe ['auth:api', 'banned', 'verified', 'onboarding'].

2.1 index — GET /api/enterprises

• utilisateur non authentifie -> 401
• utilisateur authentifie avec role !== owner -> 403 (“Only owners can access enterprises.”)
• owner -> 200, renvoie uniquement ses propres EnterpriseProfile (scope owner_id) ; les entreprises d’autres owners sont exclues

2.2 store — POST /api/enterprises

• utilisateur non authentifie -> 401
• role !== owner -> 403 (“Only owners can create enterprises.”)
• validation : name manquant -> 422 ; name > 255 -> 422 ; siren manquant -> 422 ; siren pas exactement 9 chiffres -> 422 ; email format invalide -> 422 ; phone > 20 -> 422
• happy path : cree une EnterpriseProfile rattachee a l’owner connecte (owner_id = user), 200
• geocoding : l’address est geocodee via la BAN (Http) ; succes -> latitude/longitude pre-remplies ; echec / 0 resultat -> latitude/longitude null (echec silencieux, la creation reussit quand meme)

2.3 show — GET /api/enterprises/{id}

• utilisateur non authentifie -> 401
• enterprise appartenant a l’owner connecte -> 200
• id inexistant -> 404 (“Enterprise not found.”)
• enterprise appartenant a un AUTRE owner -> 404 (scope owner_id)
• pas de check de role : un worker tombe sur 404 (aucune enterprise scoped a son id)

2.4 update — PUT /api/enterprises/{id}

• utilisateur non authentifie -> 401
• enterprise inexistante ou n’appartenant pas a l’owner -> 404
• validation : name > 255 / siren mauvais format / email invalide / phone > 20 -> 422
• update partiel : seuls les champs presents dans le payload sont modifies ; un champ absent garde sa valeur
• changement d’address -> re-geocoding ; succes -> latitude/longitude mises a jour
• geocoding en echec sur changement d’adresse -> latitude/longitude sont mises a null (et non conservees) : getCoordinatesFromAddress renvoie null sans throw, le try/catch du controller ne sert a rien et $coords['latitude'] ?? null ecrit null. Comportement destructif a signaler en section 1.
• si la position est propagee (lat/lng presents dans l’updateData) -> EnterpriseService::propagatePositionToOpenMissions est appele
• reponse : 200 avec l’entreprise fraiche

2.5 destroy — DELETE /api/enterprises/{id}

• utilisateur non authentifie -> 401
• enterprise inexistante ou non possedee -> 404
• enterprise avec au moins une mission active (status hors completed / cancel) -> 422 (“Cannot delete enterprise with active missions.”)
• enterprise sans mission, ou avec uniquement des missions completed / cancel -> supprimee (hard delete : EnterpriseProfile n’utilise PAS SoftDeletes), 200
• echec du delete -> 500 (“Failed to delete enterprise.”) — chemin d’erreur non force en test

2.6 updateStorefront — POST /api/enterprises/{id}/storefront

• utilisateur non authentifie -> 401
• enterprise inexistante ou non possedee -> 404
• validation : storefront_photo manquant -> 422 ; mime hors jpeg/jpg/png -> 422 ; > 10 Mo -> 422
• happy path : remplace l’image via ImageService::replace, persiste le nouveau front_picture, 200 ; la response contient path + url + l’enterprise fraiche