Opa, Diego. Confesso que fiquei confuso com sua dúvida. rsrs

Mas vou tentar responder:

Caso na minha implementação a Descrição for um objeto de valor esse cenário pode continuar ser descrito da mesma maneira?

Sim, não precisa mudar nada na descrição. Você vai pegar esse texto que é o parâmetro e passar para o Value Object. Sem complicações. :-)

Eu sabia que ia ficar confuso a dúvida rsrs

Vou dar um exemplo:

Eu tenho um cenário que descreve a criação de um usuário onde ele deve possuir nome e email.

A regra do nome é possuir 2 palavras e email ter um formato válido.

Eu vou criar uma classe de teste (NomeTest), por exemplo, para validar essa regra do meu objeto Nome. Via de regra vou precisar também testar a criação de um cliente com um nome inválido sendo que já tenho teste para meu objeto Nome? Vale também para o email ou demais atributos que possam ser objetos de valores.

Ah... O outro ponto que falei ao final da dúvida é em relação as features. Citando o mesmo exemplo do usuário, digamos que ele tenha um método para mudar status entre ativo e inativo. Essa "verificação de mudança de status" origina uma feature nova ou fica na mesma feature de criação de usuário como um cenário de "verificação de mudança de status"? Intuitivamente eu colocaria em uma nova feature, porém os testes das duas features ficaria na mesma classe de teste (usando xUnit), seria isso?

Aahh sim.

Então, se você já possui um teste de unidade pra cobrir esse cenário de nome ou e-mail inválido, não precisa criar um novo teste pra garantir que o usuário não será criado. Isso não vai agregar nenhum valor. Você pode criar as descrições em Gherkin dizendo que um nome precisa ter 2 palavras, que o e-mail precisa ter um formato válido, etc. Não precisa repetir isso na criação do usuário.

Quando à mudança de status, exato. Temos 2 features mas a classe de teste pode ser uma só sem problemas. :-)

Você pode criar as descrições em Gherkin dizendo que um nome precisa ter 2 palavras, que o e-mail precisa ter um formato válido, etc.

Nas regras, correto?

Quando à mudança de status, exato. Temos 2 features mas a classe de teste pode ser uma só sem problemas. :-)

Por pura consequência de sua natureza o BDD ajuda a criar os testes que agregam valores? Eu estava imaginando esse cenário do status sem seguir o BDD, de cara eu criaria na classe de teste para usuário um método para testar essa mudança de status. Porém essa mudança de status quase sempre está atrelada a uma regra de negócio, então eu testaria a mudança de status não puramente por testa-la, mas sim acoplado a um cenário. Se eu tiver imaginando muita besteira corrija-me rsrs.

Nas regras, correto?

Em cenários diferentes mesmo.

Por pura consequência de sua natureza o BDD ajuda a criar os testes que agregam valores?

Exato. A filosofia do BDD é justamente pensar na funcionalidade como ela é e quando o assunto é "testes", testamos pensando realmente em como a funcionalidade será usada. :-D