SOLID AND BDD

In this class we will discuss BDD, using some of the SOLID principles as guidelines. The learning goals include:

• Understand basic concepts of OO Design and the SOLID Principles
• Understand the concepts of BDD
• Get some experience with BDD
• Practice programming and design

In this README you can find...

• A list of concepts
• The SOLID principles
• An explanation of ODD
• Intro to Kotlin/IJ
• Interesting sources

---

Code Reviews

Code Reviews: Ask questions, make observations, help make the code better. Some Guidelines:

• Review the code, not the coder
• Review consistency, correctness and design

SOLID: Open Closed Principle

Open Closed Principle: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

• You want to be able to use info/methods from parent classes, but you don't want your subclass to be able to change the parent class
• Original Meyer defenition:

• In other words:

• It means that we should strive to write code that doesn’t have to be changed every time the requirements change: it should be reusable.

Behaviour Driven Development (BDD)

Background: Specification and Cod and "Business"

• BDD is a second-generation (TDD would be first), outside-in (rather than inside out), pull-based (You pull stuff out), multiple-stakeholder (multiple people have a say in the outcome), multiple-scale(not just for developers), high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs resulting in the delivery of working, tested software that matters.
• Dan North: Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand a why a tests fails. My response is behaviour-driven development.

Use Cases, User Stories & Scenarios

• User Cases

From tynerblain.com:

Some common elements in a use case template:

• Actor – The person or people who will perform the steps of this use case.
• Preconditions – A description of the relevant and non-trivial state(s) of the system prior to the use case starting.
• Normal course – A description of the use case itself. This description can either be in narrative form, or a numbered list (1..N) of specific user steps. When a use case (such as “User approves/rejects customer requests”) has more than one way that a user can accomplish the needed steps, the most common way is shown here – only a single path is shown.
• Alternate courses – Descriptions of alternatives to, or deviations from the normal course. For example, the most common course might be to view the oldest unaddressed customer requests. An alternate course may be to view the unaddressed requests from the largest customers.
• Exception courses – Descriptions of what the user will experience when something goes wrong.
• Post-conditions – Description of the affected portions of the state of the system after the use case has completed.
• Frequency of use – An estimate of how often a particular use case will be exercised.
• Assumptions – Any assumptions that are implicit in the definition of the use case.

• User Stories:

As a [A]

I want [Y]

so that [Z]

• Scenarios:

Given some initial context (Assign)

When an event occurs (Act)

then ensure some outcomes (Assert)

BDD Principles

According to Dan North

• Test method names should be sentences
• A simple sentence template keeps test methods focused
• An expressive test name is helpful when a test fails
• Behaviour is a more useful word thatn test
• Determine the next most important behaviour
• Requirements are behaviour, too
• BDD provides a ubiquitours language for analysis
• Acceptance criteria should be executable

Techniques

• Frameworks and DSL's (xBehave, xSpec, Gherkin)

^This is a Gherkin example^

• A framework for collaboration and clarity

Assignments

• Most assignments can be found in ./Kata/src/test/kotlin
• We also build a project with multiple people. You can find the repo here.

Kotlin

Mutable vs Immutable lists

• Languages like Java have a shared memory model
• Basic types are almost always value types, which are immutable (if you reassign them, a copy of the original value will be made, which is good for functional programming)
• Other types are reference types, they store the reference to the space in where the the values are memorized. These are mutable (and super fast, because you don't have to copy code each time you reassign something)
• Lists in Kotlin are by default immutable. If they would be mutable, they might react unpredictably when two methods try to access that memory space at the same time.
• Use immutable types if you use parallel processing (paralellism), because there are no side effects
• Check joelabrahmsson.com for more info and an example.

Q&A

How can I extend legacy code?

• Set up boundaries, isolate your code (+ that that it is coupled to)
• Read the book Working with legacy code by M. Feathers

What is good testing?

• A test that has one Assert and that is readable
• It is easier to define bad tests.

Interesting Sources

• About working with legacy code: Working Effectively With Legacy Code, M. Feathers
• About the open Closed Principle: JoelAbrahamsson.com
• BDD: Dan North - Introducing BDD
• Use Cases: TynerBlain.com
• Specification by Example
• Refactoring: Refactoring by Kent Beck