‘generate post template’ - ‘Turn on toc’ - set tags write text above summary delimiter - write rest of post beneath - launch server and wire markdown as html - verify all translations from data are correct in html - verify accessibility WCAG 2.1 AA - verify deep links - verify copy code - verify toc collapse - verify toc is displayed

Create a test of your end to end system so you can
Testing in production is beneficial. A milestone for teams to achieve is to be able to generate data in the system and verify the presentation of it is correct as the users will experience it.

In this case that means generating the blog post using the generator, editing the page contents, and confirming it is correct across different browsers.

We can test anything that transforms based on that data and by pinning it to the test suite in a way that asserts what we are looking for, we can catch when a failure occurs.

If you have the ability to test the complete flow, then you can upgrade, swap out, and change any of the intermittent parts of your process.

Implementing this approach I have found devs delight in what was previously worrying. One upgraded a framework version, fixed the compilation errors, and with the tests green we were good to go.

Build this capability in when the system is small, so that you can evolve your architecture around your ability to verify the system. Over my years of experience I’ve learned to appreciate how much changes in a system. Device operating systems, submarine cable , browsers, programming language versions, frameworks, dependencies explicit or implicit, cloud runtimes, networking changes, CVE vulnerabilities, securing software supply chains, and visions of better ways to delight and serve your clients.

There are many reasons change will be required in a software system. Software varies immensely and if you build a solid feedback loop your team can build confidence and courage to

Test in production. Change is constant in software. New library versions. New operating systems. New cloud runtimes.

Maintain momentum. Be responsive and receptive to requests and requirements to change. If you can deliver a better experience, more value, more security, accessibility, respond to regulatory requirements.

Posts are created using a template.
The post itself is constructed from partials. You might want to run your tests to verify all of the computed partials and sections are rendered correctly, and run the test on all of the browsers/form factors you use.

If your core flow fails and users can’t give you money or receive the positive impact of your platform then you should know about that.

It will:

• Test the title ‘Test in Production’
• Test the date format
• Test the toc is shown
• Test the toc has Header(s)
• Test the toc is visible
• Test clicking the toc button hides the toc, and clicking again shows it again.
• Test code blocks shall have copy to clipboard button
• Test clicking copy to clipboard button copies code to the clipboard
• Test linenos=inline adds line number to the left side.
• Test anchorLineNos allows you to click on the anchor, and url changes to the line and focuses it
• Test lineAnchors=“code” puts the ‘code’ in the url http://localhost:1313/posts/test-in-production/#code-5
• Test clicking line ‘5’ ends the url as #code-5
• Test navigating to the url moves the code block into view, and the title is not in view
• Test lines 3 and 7 are highlighted
• Test every code block renders exactly one copy button
• Test copying a block with line numbers excludes the line numbers
• Test copying a block with highlighted lines excludes no code and adds no markers
• Test all four variants below copy byte-identical text
• Test the copied text has no trailing blank line

Go code with highlights

1package main
2
3import "fmt"
4
5func main() {
6	for i := 0; i < 3; i++ {
7		fmt.Println("Value of i:", i)
8	}
9}

Copy to clipboard variants

The same program four ways. Only the Chroma options differ, so the copy button
should produce identical text from all four.

Plain code - no line numbers, no highlighting

package main

import "fmt"

func main() {
	for i := 0; i < 3; i++ {
		fmt.Println("Value of i:", i)
	}
}

Code with highlighting

package main

import "fmt"

func main() {
	for i := 0; i < 3; i++ {
		fmt.Println("Value of i:", i)
	}
}

Code with line numbers

1package main
2
3import "fmt"
4
5func main() {
6	for i := 0; i < 3; i++ {
7		fmt.Println("Value of i:", i)
8	}
9}

Code with line numbers and highlighting

1package main
2
3import "fmt"
4
5func main() {
6	for i := 0; i < 3; i++ {
7		fmt.Println("Value of i:", i)
8	}
9}

Jenkins Pipeline Script

 1pipeline {
 2    agent any
 3    stages {
 4        stage('Build') {
 5            steps {
 6                //
 7            }
 8        }
 9        stage('Test') {
10            steps {
11                //
12            }
13        }
14        stage('Deploy') {
15            steps {
16                //
17            }
18        }
19    }
20}

Green means go. Build confidence in your tests.