---
title: "Testar o Custom Code GoodBarber com um membro ligado"
description: "Precisa que o seu Custom Code do GoodBarber se comporte de forma diferente para um utilizador autenticado — mostrar conteúdo premium, saudar um membro pelo nome"
canonical_url: "https://pt.goodbarber.com/blog/testar-o-custom-code-goodbarber-com-um-membro-ligado-a1291/"
lang: pt
date: 2026-06-26
last_updated: 2026-07-17
---

# Testar o Custom Code GoodBarber com um membro ligado

[Voltar](/blog/make-it-r19/)

# Testar o Custom Code GoodBarber com um membro ligado

Escrito por [Mathieu Poli](https://pt.goodbarber.com/blog/author/mathieu-poli/)  na Sexta-Feira 26 Junho 2026

## Precisa que o seu Custom Code do GoodBarber se comporte de forma diferente para um utilizador autenticado — mostrar conteúdo premium, saudar um membro pelo nome, esconder uma secção dos visitantes anónimos? Quer tenha escrito esse código por si próprio ou o tenha gerado com o AI Extension Builder, ele pergunta à App API quem está ligado através de gb.user.getCurrent(). Mas a pré-visualização do back-office não tem login real, por isso, em apps com Membership, essa chamada cai sempre no caminho de erro. Este guia explica como o utilizador atual se comporta na pré-visualização para cada tipo de app e dá-lhe uma forma de copiar e colar para testar como um membro autenticado.

![](https://cmsphoto.ww-cdn.com/superstatic/121801/art/grande/97133651-67674243.jpg?v=1782463732.8524148)

Muito Custom Code precisa de saber **quem está a usar a app neste momento**: mostrar conteúdo premium, saudar membros pelo nome, esconder uma secção dos visitantes anónimos, adaptar um checkout. A App API do GoodBarber dá-lhe acesso ao utilizador atual através de `gb.user.getCurrent()`.

E o Custom Code já não é apenas algo que se escreve à mão. Com o **[AI Extension Builder](https://pt.goodbarber.com/blog/ai-extension-builder-crie-secoes-com-ia-sem-programar-a1242/)** do GoodBarber, descreve em linguagem natural a secção que pretende e o assistente gera a extensão por si — código que se liga diretamente à mesma App API do GoodBarber. Escrito à mão ou gerado por IA, ele chama `gb.user.getCurrent()` da mesma forma, e você testa-o da mesma forma. Por isso, este guia aplica-se tanto se escreveu o código como se o pediu por prompt.

Mas eis o obstáculo com que todo o programador acaba por se deparar: **dentro da pré-visualização do back-office, não existe nenhum utilizador autenticado.** A pré-visualização é apenas uma renderização da sua app — não há ecrã de login, não há sessão, não há nada contra o qual autenticar.

Para a maioria dos tipos de app, o GoodBarber contorna isto discretamente por si, de modo que testar "como um utilizador autenticado" simplesmente funciona. Para a extensão **[Membership](https://pt.goodbarber.com/blog/assinaturas-estao-aqui-a990/)**, não funciona — e isso é intencional. Este artigo percorre como o utilizador atual se comporta na pré-visualização para cada tipo de app e dá-lhe uma forma simples, de copiar e colar, de testar o caso mais complicado: um **membro** autenticado.

## Uma revisão rápida: gb.user.getCurrent()

A App API do GoodBarber permite ao seu Custom Code perguntar "quem está a usar a app neste momento?" através de um único método:

gb.user.getCurrent( (user) => { // Há um utilizador autenticado. // `user` é um objeto GBUser — leia os seus atributos aqui. console.log(user.email); }, (error) => { // Não há nenhum utilizador autenticado. console.log(`Response status: ${error.code}`); console.log(`Response message: ${error.message}`); } );

Recebe **dois callbacks**: um callback de sucesso (chamado com um objeto `GBUser` quando alguém está autenticado) e um callback de erro (chamado quando ninguém está autenticado). É baseado em callbacks — **não** devolve um valor nem uma Promise.

**O objeto *GBUser* muda de forma consoante o tipo de app**

O modelo `GBUser` carrega uma propriedade `api_version` que indica que tipo de app o produziu:

| `api_version` | Tipo de app                                   |
| ------------- | --------------------------------------------- |
| `1`           | App de conteúdo **+ extensão Authentication** |
| `2`           | App **eCommerce**                             |
| `3`           | App de conteúdo **+ extensão Membership**     |

A lista de atributos depende dessa versão. Para uma app **Membership** (`api_version: 3`), um `GBUser` tem este aspeto:

{ id: 123, api_version: 3, login: "member@example.com", email: "member@example.com", username: "John Doe", firstname: "John", lastname: "Doe", picture_url: "https://example.com/picture.jpg", access_levels: ["premium"] // 👈 o campo-chave para Membership }

O array `access_levels` é o que torna o Membership especial: lista os níveis de acesso que o utilizador detém no momento. É quase sempre com base nisto que o seu Custom Code se ramifica ("este utilizador tem `premium`? então mostra o conteúdo bónus").

Na prática, o seu código lê `access_levels` para decidir o que mostrar:

gb.user.getCurrent( (user) => { if (user.access_levels.includes("premium")) { console.log("O membro tem premium — mostrar o conteúdo premium"); } else { console.log("Autenticado, mas sem premium — mostrar a sugestão de upgrade"); } }, (error) => { console.log("Ninguém autenticado — mostrar o prompt de login"); } );

Tenha isto em mente — é exatamente este código que o mock abaixo vai alimentar.

## Como o utilizador atual se comporta na pré-visualização

A pré-visualização no back-office é um sandbox. Renderiza a sua app, mas **não tem mecanismo de login** — não há forma de autenticar realmente um utilizador real dentro dela.

Para que o desenvolvimento continue a ser confortável mesmo assim, o GoodBarber **injeta um utilizador fictício** para alguns tipos de app, de modo que `getCurrent()` devolva *algo* com que possa trabalhar:

| Tipo de app                                  | Na pré-visualização, `getCurrent()`…                                                                       |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Add-on **Authentication** (`api_version: 1`) | ✅ Devolve automaticamente um **utilizador fictício** — o seu callback de sucesso é executado.              |
| App **eCommerce** (`api_version: 2`)         | ✅ Devolve automaticamente um **cliente fictício** — o seu callback de sucesso é executado.                 |
| Extensão **Membership** (`api_version: 3`)   | ❌ **Não devolve nada** — o seu callback de **erro** é executado com `"There's no user logged in the app."` |

Assim, se a sua app usar **Authentication** ou **eCommerce**, pode testar a sua lógica de utilizador autenticado na pré-visualização de imediato — é-lhe entregue um utilizador fictício gratuitamente, sem qualquer configuração.

Se a sua app usar a extensão **Membership**, é diferente: **não é injetado nenhum utilizador fictício.** Se o seu callback de sucesso nunca é executado na pré-visualização e cai sempre no caminho de erro, isso é o esperado — simplesmente não há utilizador atual para devolver e, ao contrário dos outros dois tipos de app, nenhum é simulado por si.

O resto deste artigo foca-se nesse caso do Membership, porque é o que precisa de algum trabalho. Tem duas formas de o resolver.

## Opção 1 — Testar na app MyGoodBarber (condições reais)

A forma mais fiel de testar é executar a sua app dentro da app **MyGoodBarber** (disponível em iOS e Android). Ela carrega a sua app real, com o fluxo de login real e o backend real. Você autentica-se como um membro verdadeiro e `getCurrent()` devolve o seu `GBUser` real com os seus `access_levels` reais.

Use isto quando quiser validar o fluxo *completo* de ponta a ponta antes de publicar. É o mais próximo possível da produção.

A desvantagem: é um ciclo de feedback mais lento. Não consegue iterar sobre um ajuste de CSS ou sobre uma ramificação condicional tão depressa como na pré-visualização. É aí que entra a Opção 2.

## Opção 2 — Simular (mock) getCurrent() na pré-visualização

Para iterar rapidamente, pode **substituir temporariamente** `gb.user.getCurrent` por uma versão sua que devolve um membro fictício à sua escolha. A sua lógica real permanece exatamente igual — o seu Custom Code continua a chamar `gb.user.getCurrent(success, error)` como sempre. Está apenas a trocar *o que o método faz* enquanto testa.

**Passo 1 — Inserir o mock no topo do seu código**

Adicione este bloco mesmo no início do JavaScript do seu Custom Code, antes de qualquer chamada a `getCurrent()`:

// ⚠️ APENAS PARA TESTE NA PRÉ-VISUALIZAÇÃO — remova (ou defina como false) antes de publicar! const PREVIEW_TESTING = true; if (PREVIEW_TESTING && typeof gb !== "undefined" && gb.user) { gb.user.getCurrent = function (successCallback, errorCallback) { const fakeUser = { id: "123", api_version: 3, login: "member@example.com", email: "member@example.com", username: "Test Member", firstname: "Test", lastname: "Member", picture_url: "", access_levels: ["premium"] // 👈 altere isto para testar casos diferentes }; successCallback(fakeUser); }; }
> 💡 `"premium"` é apenas um exemplo. Use os **identificadores de níveis de acesso reais configurados na sua app** — caso contrário, as suas condições não vão corresponder a nada.

Pode perguntar-se: o meu código não consegue detetar a pré-visualização e simular apenas aí? Infelizmente, não — não existe nenhum sinal fiável exposto ao seu Custom Code que diga "isto é a pré-visualização" (`gb.platform()` devolve `"web"` na pré-visualização, exatamente como uma PWA real em produção) e, só a partir de `getCurrent`, a pré-visualização é indistinguível de um utilizador genuinamente desconectado (ambos caem no callback de erro). É por isso que usamos uma flag que se alterna **à mão**: é explícita e não pode ser acionada por acidente em produção.

E é tudo. A partir de agora, em qualquer ponto do seu Custom Code onde chame:

gb.user.getCurrent(onUserFound, onNoUser);

…o seu callback `onUserFound` recebe o membro fictício acima — exatamente como se um membro `premium` real estivesse autenticado. **Não altera nada da sua lógica de negócio**; apenas acrescentou o bloco de mock por cima.

**Passo 2 — Testar os casos que importam**

Todo o objetivo do código de Membership é reagir a utilizadores *diferentes*. Basta editar o mock para cobrir cada cenário:

**Um membro subscrito (com níveis de acesso):**

access_levels: ["premium"]

**Um utilizador autenticado sem subscrição:**

access_levels: []

**Vários níveis de acesso ao mesmo tempo:**

access_levels: ["free", "premium", "vip"]

**Ninguém autenticado** — aqui simula o caminho de *erro* em vez do de sucesso:

gb.user.getCurrent = function (successCallback, errorCallback) { errorCallback({ code: 1, message: "There's no user logged in the app." }); };

Alterne entre estes casos para garantir que o seu Custom Code se comporta corretamente em todos os estados — e não apenas no caminho feliz.

**Passo 3 (opcional) — Simular também *gb.membership.getAccessLevels()***

Algum código de Membership lê os níveis de acesso através do método dedicado do Membership em vez de o fazer pelo objeto do utilizador:

gb.membership.getAccessLevels( (access_levels) => { console.log(access_levels); }, (error) => { console.log(error.message); } );

Se o usar, simule-o da mesma forma:

if (PREVIEW_TESTING && typeof gb !== "undefined" && gb.membership) { gb.membership.getAccessLevels = function (successCallback, errorCallback) { successCallback(["premium"]); }; }

## ⚠️ Antes de publicar: desligue o mock

Esta é a única regra que não pode saltar. O mock é uma muleta de desenvolvimento — **nunca pode chegar à produção.** Se o publicar, todos os utilizadores da app serão tratados como o seu membro `premium` fictício, independentemente daquilo que realmente pagaram.

Dois hábitos seguros:

1. Mantenha tudo por trás da única flag `PREVIEW_TESTING` e defina-a como `false` antes de publicar.
2. Melhor ainda, **elimine completamente o bloco de mock** assim que terminar de testar.

Quando `PREVIEW_TESTING` é `false` (ou o bloco desaparece), `gb.user.getCurrent` volta à implementação real do GoodBarber e o seu Custom Code passa a funcionar com membros realmente autenticados.

Pronto para experimentar? Abra a secção **Custom Code** no seu back-office do GoodBarber, cole o bloco de mock no topo do seu JavaScript e defina os `access_levels` para o caso que quer testar. Quando tudo se comportar como esperado, mude `PREVIEW_TESTING` para `false` (ou elimine o bloco) e publique. Para a referência completa, consulte a [documentação da App API](https://app.goodbarber.dev/v2/documentation/).

E se preferir não escrever a extensão à mão, é aí que entra o **AI Extension Builder**: descreva em linguagem natural a secção que pretende e ele gera a extensão, liga-a às próprias APIs do GoodBarber e renderiza-a ao vivo na sua app. Assenta na mesma App API — por isso a técnica acima está logo à mão sempre que quiser pré-visualizar como a sua extensão se comporta para um membro autenticado.

## Leitura adicional

- [`gb.user.getCurrent`](https://app.goodbarber.dev/v2/documentation/#tag/user-methods/operation/gb.user.getCurrent) — obter o utilizador autenticado atual.
- [`GBUser`](https://app.goodbarber.dev/v2/documentation/#tag/user-models/operation/GBUser) — o modelo do utilizador e como os seus atributos mudam consoante o `api_version`.
- [`gb.membership.getAccessLevels`](https://app.goodbarber.dev/v2/documentation/#tag/membership-methods/operation/gb.membership.getAccessLevels) — ler os níveis de acesso diretamente (disponível apenas com o add-on Memberships).
- [GoodBarber para programadores: mais liberdade e ferramentas para utilizadores avançados](https://pt.goodbarber.com/blog/goodbarber-open-mais-liberdade-para-desenvolvedores-e-usuarios-avancados-a1142/) — o que pode construir para além do editor no-code.

## Recapitulação

- Na pré-visualização do back-office, **não há login real**.
- Para apps **Authentication** e **eCommerce**, o GoodBarber injeta automaticamente um utilizador fictício, por isso testar como um utilizador autenticado simplesmente funciona.
- Para a extensão **Membership**, **não é fornecido nenhum utilizador fictício** — `getCurrent()` cai no callback de erro.
- Para testar rapidamente na pré-visualização, **substitua temporariamente `gb.user.getCurrent`** (e `gb.membership.getAccessLevels`, se o usar) para devolver um membro fictício com os `access_levels` que quer testar.
- Para uma verificação real, de ponta a ponta, execute a sua app dentro da app **MyGoodBarber**.
- **Remova sempre o mock antes de publicar.**

## FAQ

**Porque é que `gb.user.getCurrent()` devolve um erro na pré-visualização para a minha app Membership?**

Porque a pré-visualização do back-office não tem mecanismo de login e, para apps Membership (`api_version: 3`), o GoodBarber não injeta um utilizador fictício. Sem ninguém autenticado, o método chama o seu callback de erro com `"There's no user logged in the app."` — é o comportamento esperado, não um bug.

**Porque é que o mesmo código funciona na pré-visualização para uma app Authentication ou eCommerce?**

Para apps Authentication (`api_version: 1`) e eCommerce (`api_version: 2`), o GoodBarber injeta automaticamente um utilizador fictício (ou cliente fictício) na pré-visualização, por isso o seu callback de sucesso é executado sem qualquer configuração.

**Como testo um membro autenticado sem publicar a minha app?**

Pode executar a sua app dentro da app MyGoodBarber (iOS/Android) para testar em condições reais, ou substituir temporariamente `gb.user.getCurrent` no seu Custom Code para devolver um membro fictício com os `access_levels` que quer testar.

**O que é `access_levels` no objeto `GBUser`?**

É um array dos níveis de acesso que um utilizador Membership detém no momento (por exemplo `["premium"]`). O seu Custom Code normalmente ramifica-se com base nele para decidir que conteúdo mostrar. Um array vazio (`[]`) significa um utilizador autenticado sem subscrição ativa.

**`gb.user.getCurrent()` devolve uma Promise?**

Não. É baseado em callbacks: passa um callback de sucesso e um callback de erro. Não devolve um valor, por isso não pode usar `await`.

**O que acontece se eu me esquecer de remover o mock antes de publicar?**

Todos os utilizadores da sua app serão tratados como o membro fictício que codificou diretamente — todos receberiam, por exemplo, acesso `premium` independentemente do que realmente pagaram. Defina sempre `PREVIEW_TESTING` como `false` ou elimine o bloco de mock antes de publicar.

- [#Como Fazer](https://pt.goodbarber.com/blog/tags/como%20fazer)

![Mathieu Poli](https://blog.goodbarber.com/_public/profile/65/6553d00ecdbe15f8aac2da7dddcff47648fdd791-default.jpg)

Sobre o autor[Mathieu Poli](https://pt.goodbarber.com/blog/author/mathieu-poli/)Head of Frontend Engineering

Sou Head of Frontend Engineering na GoodBarber

Supervisiono as equipas que concebem os motores de renderização no coração da nossa plataforma no-code: são elas que dão vida aos projetos dos nossos utilizadores e os transformam em aplicações nativas, fluidas e cuidadas. Tudo o que se vê e se manipula no ecrã passa pelas suas mãos.
Pioneiro do no-code móvel, apaixonado por arquitetura de software e design de produto, também dou aulas em universidades e escolas privadas.

Aqui escrevo sobre engenharia frontend, design de produto e IA — e sobre tudo o que acontece quando estes três mundos se encontram.

[Saiba mais](https://pt.goodbarber.com/blog/author/mathieu-poli/)

[![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/hellomathieup)[![X](https://portal.ww-cdn.com/portal_static/svg/base2021/x.820492c586dd.svg)](https://x.com/hellomathieup/)