My TDD Pilgrimage

            
    func TestBlog_GetSummary(t *testing.T) {
        t.Run("should return empty string for empty content", func(t *testing.T) {
            //Input: ""
            //Output: ""
        })

        t.Run("Should return only the first html tag", func(t *testing.T) {
            //Input: "
Some content
Some more content
"
            //Output: "
Some content
"
        })

        t.Run("Should return only the first html with all sub tags tag", func(t *testing.T) {
            //Input: "
Captain Kathryn Janeway
Some more content
"
            //Output: "
Captain Kathryn Janeway
"
        })
    }
            
        

            
    func TestBlog_GetSummary(t *testing.T) {
       t.Run("should return empty string for empty content", func(t *testing.T) {
            b := &Blog{Title: "Some Title", Content: "", State: Draft}
            if got := b.GetSummary(); got != "" {
                t.Errorf("GetSummary() = %v, want %v", got, "")
            }
        })

        t.Run("Should return only the first html tag", func(t *testing.T) {
            //Input: "
Some content
Some more content
"
            //Output: "
Some content
"
        })

        t.Run("Should return only the first html with all sub tags tag", func(t *testing.T) {
            //Input: "
Captain Kathryn Janeway
Some more content
"
            //Output: "
Captain Kathryn Janeway
"
        })
    }
            
        

            
    func (b *Blog) GetSummary() (string) {
	    return ""
    }
            
        

            
    func TestBlog_GetSummary(t *testing.T) {
       t.Run("should return empty string for empty content", func(t *testing.T) {
            b := &Blog{Title: "Some Title", Content: "", State: Draft}
            if got := b.GetSummary(); got != "" {
                t.Errorf("GetSummary() = %v, want %v", got, "")
            }
       })

        t.Run("Should return only the first html tag", func(t *testing.T) {
            b := &Blog{
                Title:   "A New Title",
                Content: "
Some content
Some more content
",
                State:   Draft,
            }
            if got := b.GetSummary(); got != "
Some content
" {
                t.Errorf("GetSummary() = %v, want %v", got, "
Some content
")
            }
        })

        t.Run("Should return only the first html with all sub tags tag", func(t *testing.T) {
            //Input: "
Captain Kathryn Janeway
Some more content
"
            //Output: "
Captain Kathryn Janeway
"
        })
    }
            
        

            
    func (b *Blog) GetSummary() (summary string) {
        reader := strings.NewReader(b.Content)
        tokenizer := html.NewTokenizer(reader)

        for {
            tokenType := tokenizer.Next()
            token := tokenizer.Token()
            switch tokenType {
            case html.StartTagToken:
                summary += token.String()
            case html.TextToken:
                summary += token.Data
            case html.EndTagToken:
                summary += token.String()
                return summary
            }
        }
    }
                
        

• Improved code quality: You start by writing a list of test scenarios listed out first. You are thinking about inputs and edge cases first. This leads to decreased chances of missing requirements, and introducing bugs.
• Upholding the test pyramid: Unit tests are always cheaper to write and run. When you focus so much on writing unit tests before code you are absolutely building a solid base of the testing pyramid.
• Maintainable and extensible code: The chances of writing “clean code” significantly increase when you write tests first. Why do I make this claim - to allow your code to be testable you need to start thinking of how you would design your code first? When you consider code design before diving into coding, you start thinking about cohesion, testability, and low coupling, leading to patterns such as dependency injection and the single-responsibility principle. All this leads to maintainable, testable and extensible code blocks at core.
• Better documentation: Well written test scenarios are live documentation of the code. They need to get updated to keep the builds green. These documents seldom go out of date. Additionally, they make on-boarding and context sharing easier for teams.
• Speed: There is a perception that TDD slows us down. On the contrary, TDD saves time by delivering higher quality code upfront. Additionally, it brings design thinking first, leading to code which is highly extensible and maintainable in future. All these are efficiencies you need to go faster.