Skip to main content

Home/ SoftwareEngineering/ Group items tagged BDD

Rss Feed Group items tagged

kuni katsuya

Preemptive commit comments | Arialdo Martini - 0 views

  • Tell me what the software does
    • kuni katsuya
       
      tell me how the software should *behave*, not how the behavior was *implemented* ie. describe the changes in this commit from the behavioral perspective rather than implementation details
  • What is the project behavior, in this snapshot?
  • What did the programmers, in order to produce this snapshot?
  • ...43 more annotations...
  • committing comments describing the
  • behavior of the software,
  • rather than the
  • implementation or a description of what we did
  • commits’ comments started to look like BDD’s methods name: a description of a behavior.
  • principles
  • Talk about the feature, not about yourself
  • Don’t refer to the past
  • I know it’s now
  • list of benefits
  • More focus while developing
  • Commit review is much easier
  • Less cognitive load
  • You learn commenting much more precisely
  • commit comment becomes a
  • declaration of intent
  • like a BDD method name
  • No more “Just a fix“, “Improvements” or “I made this, this, this and also this” comments.
    • kuni katsuya
       
      BDD/TDD or any methodology aside, these are the worst commit comments as they are as useless as empty commit comments
  • Each preemptive comment triggers a micro design session
  • A preemptive comment sets a micro goal
    • kuni katsuya
       
      which also aligns well with the 'micro goal' or incremental deliverables approaches of most agile methodologies 
  • helps to focus a goal to be reached
  • Without preemptive comments, I often went on coding, always asking myself: “Should I commit now? Have I reached a stable state which I could consider a good commit?“
  • define micro-goals through preemptive comments
  • macro-goal through the feature branch name
  • A preemptive comment creates a little timebox
    • kuni katsuya
       
      similar to the timeboxing strategy of a short sprints, for instance
  • Writing comments preemptively puts the agreement between the pair members to a test
    • kuni katsuya
       
      more relevant to methodologies using pair programming
  • commit history gains a very balanced granularity
  • feature branch becomes a collection of evolutionary commits each of which has usually a 1:1 binding with tests
  • very easy to find which commit introduced a bug, since each commit is related to a single new goal/feature
  • Preemptive commit comments
  • Rule #2: write what the software
  • I started taking a lot of care of the words I was using in comments, commits, test names and classes/variables/methods’ names
  • be supposed to do,
  • not what you did
  • should
  • Introducing BDD
  • began with the simple attempt to replace the world
  • “should“
  • “test”
  • with the world
  • Rule #1: write commit comments before coding
  • use the same criteria for my commits’ comments as well.
  • (not what you did)
kuni katsuya

What is JBehave? - 0 views

  • JBehave is a framework for Behaviour-Driven Development
  • five-step overview
kuni katsuya

A proper way for JPA entities instantiation « Paul Szulc's Blog - 0 views

  • A proper way for JPA entities instantiation
  • creating the entities I would like to focus in this post
  • JPA2.0 entities
  • ...31 more annotations...
  • UserService
  • UserDao
  • FacebookWS
  • User u
  • UserService uses UserDAO and FacebookWS
  • but don’t know how those dependencies are instantiated
  • And you shouldn’t really care, all that is important is that UserService depends on dao and webservice object.
  • BDD template given-when-then) tests are easy to read
  • @Entity
  • public class User
  • calling new User(“someName”,”somePassowrd”, “someOtherName”, “someOtherPassword”) becomes hardly readable and maintainable
  • code duplication
  • Maintaining this code would turn into a nightmare in no time
  • running the code above will throw an exception by the JPA provider,
  • since not-nullable password field was never set.
  • Joshua Blooch gives fine example of builder pattern.
  • Instead of making the desired object directly, the client calls a constructor (or static factory) with all of the required parameters and gets a builder object. Then the client calls setter-like methods on the builder object to set each optional parameter of interest. Finally, the client calls a parameterless build method to generate the object, which is immutable. The builder is a static member class of the class it builds.
  • Coffee
  • public static class Builder
  • Builder(CoffeeType type, int cupSize)
  • Builder withMilk()
  • Coffee build()
  • Coffee(this)
  • private Coffee(Builder builder)
  • Coffee coffee = new Coffee.Builder(CoffeeType.Expresso, 3).withMilk().build();2}
  • especially if most of those parameters are optional.
  • For all entity attributes I create private fields
  • those that are obligatory become parameters for the public constructor
  • parameter-less constructor, I create one, but I give him
  • protected access level
  • protected
1 - 4 of 4
Showing 20 items per page