Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'm going to call out some uses of BDD rather than just the framework, as I think having a really great understanding of unit-level BDD might affect some of the things you create. Overall, I like it. Here goes:</p> <p>Rather than calling them <code>PersonAttacksZombieTests</code>, I'd just call them <code>PersonTests</code> or even <code>PersonBehaviour</code>. It makes it much easier to find the examples associated with a particular class this way, letting you use them as documentation.</p> <p>It doesn't look like <code>IsStillAlive</code> is the kind of thing you'd want to set on a person; rather an intrinsic property. Careful making things like this public. You're adding behaviour that you don't need.</p> <p>Calling <code>new Person(null)</code> doesn't seem particularly intuitive. If I wanted to create a person without a weapon, I would normally look for a constructor <code>new Person()</code>. A good trick with BDD is to write the API you want, then make the code underneath do the hard work - make code easy to use, rather than easy to write.</p> <p>The behaviour and responsibilities also seem a bit odd to me. Why is the person, and not the zombie, responsible for determining whether the person lives or dies? I'd prefer to see behaviour like this:</p> <ul> <li>A person can be equipped with a weapon (via <code>person.Equip(IWeapon weapon)</code>).</li> <li>A person starts with a fist if they have no weapon.</li> <li>When the person attacks a zombie, the person uses the weapon on the zombie.</li> <li>The weapon determines whether the zombie lives or dies.</li> <li>If the zombie is still alive, it attacks back. The zombie will kill the person (via <code>person.Kill</code>).</li> </ul> <p>That seems to me as if it's got the behaviour and responsibilities in a better place. Using a different kind of weapon for useless attacks, rather than checking for null, also allows you to avoid that <code>if</code> statement. You'd need different tests:</p> <ul> <li>A fist should not kill a zombie when used against it</li> <li>A chainsaw should kill a zombie when used against it</li> <li>A person should use their equipped weapon when attacking a zombie</li> <li>A person should be equipped with a fist if they have no other weapon</li> <li>A zombie should attack back when it's still alive.</li> <li>A zombie should not attack back if it's dead.</li> <li>A zombie should die if killed.</li> <li>A person should die if killed.</li> </ul> <p>Other than that, it looks great. I like the way you've used the mocks, the flow of strings, and the phrasing of the test methods themselves. I also quite like <code>ProveBy</code>; it's doing exactly what it says on the tin, and nicely ties up the difference between providing examples of behaviour and running them as tests.</p>
    singulars
    1. This table or related slice is empty.
    1. POBDD for C# NUnit
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USLunivore
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COHah! I totally agree. My example is terrible, but it gets the point across about ProveBy. I'll definitely have to find time to update it.
      singulars
      1. PO
      1. USmjezzi
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload