Test-Driven Development Demonstration

2026-09-06T00:00:00+00:00

Introduction

This is a tutorial in Test Driven Development(TDD) in Java using `Leetcode’s challenge “Best Time to Buy and Sell Stock III” ¹. It covers some basic Java setup and a work-through of an interview-style problem.

Kent Beck's Book Test-Driven Development By Example provides an informal three-part mantra.²

Red --- Write a little test that doesn't work, and perhaps doesn't even compile at first

Green --- Make the test work quickly, committing whatever sins necessary in the process.

Refactor --- Eliminate all of the duplication created in merely getting the test to work.

The right way to write software is the way that works. The way that works depends on the context. Many companies’ production methods are test-driven. A programmer at such a shop does nobody any favors by vibecoding unit tests after the fact. It helps to learn learn the organization’s house style.

There are no rules, just tools.

--- Glen Vipplu

Setup

Dependencies and Assumptions

Software

Leetcode’s interpreter uses Java version 25, so the programmer needs version 25 or higher.³.

To create the project and run its tests, the programmer also needs Apache Maven. Maven is a "build tool for Java projects"⁴ that automates the boilerplate. That includes the project’s directory structure, file names, class names and test scaffholding. Yes, but can be written by hand, but Java is so verbose that and we want to reduce manual configuration.

Skills

In addition to basic Computer Science concepts (like array indexing) and jargon, the programmer should already familiar with their operating system's package manager and terminal. Everybody's package manager is different, so we're not covering how to install and update software. It's assumed the programmer has a favorite (brew, apt etc) and knows how to use it. I wrote this tutorial on a Mac, so Windows or Powershell users may need to adapt their own commands as necessary.

First, confirm Java and Maven(mvn) are installed.

java --version
mvn --version

If either --version call returns command not found, then they need to be installed(and that's out of scope here).

Creating the Project

Generating from the Maven Archetype

To create a project from a template, use the command mvn archetype:generate.“Archetype” is the Maven term for a project template. The default template is maven-archetype-quickstart. Even when using defaults, values are still needed for group id, artifact id, package and version.

Here’s what I used for this tutorial.

field	value
group id	`com.programming_grimoire`
artifact id	`tdd_demo`
package	`com.programming-grimoire.buy_sell_stock_iii`
version	`1.0.0`

mvn archetype:generate runs interactively by default. It can also be run in batch mode (the -B flag) to pass in all the parameters at once.

mvn archetype:generate -B -DgroupId=com.programming_grimoire -DartifactId=tdd_demo -Dversion=1.0.0. -Dpackage=com.programming_grimoire.buy_sell_stock_iii

NOTE: For the interest of sanity, console output here is truncated.

...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

Maven built a project complete with a pom.xml file, starter app and test.

tdd_demo
|-- pom.xml
|-- src
   |-- main
   |   |-- java
   |       |-- com
   |           |-- programming_grimoire
   |               |-- buy_sell_stock_iii
   |                   |-- App.java
   |-- test
       |-- java
           |-- com
               |-- programming_grimoire
                   |-- buy_sell_stock_iii
                       |-- AppTest.java

12 directories, 3 files

Hardening the POM

The P.O.M. in pom.xml stands for Project Object Model, and the file is Maven's representation of the project. The generated POM is functional but minimal; building with it as-is throws out [WARNING] leaders in the output.

Warnings don't break the build, but they:

remain harmless until the worst possible moment
add noise to the outputs
annoy the programmer

For text, my machine uses UTF-8 encodings as a default. Use an xml tag to spell it out for Maven.

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

In this example, Maven uses Java 26. If the Java version isn’t secured, the project may compile using an earlier release.

<maven.compiler.release>26</maven.compiler.release>

The source encoding and version specifications go in the POM's properties field.

<properties>
 <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 <maven.compiler.release>26</maven.compiler.release>
</properties>

It goes in the top-level project tag so the final POM looks like the example below.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.programming_grimoire</groupId>
  <artifactId>tdd_demo</artifactId>
  <packaging>jar</packaging>
  <version>1.0.0.</version>
  <name>tdd_demo</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <properties>
   <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
   <maven.compiler.release>26</maven.compiler.release>
  </properties>
</project>

Running the Tests

Let's go over running tests, project cleaning and introducing some shorthand to cut the blocks of output in this tutorial. Running the tests is simple; use mvn test from inside the project directory.

Basic Case

The content of AppTest has one boilerplate test named testApp.

public void testApp()
   {
       assertTrue( true );
   }

Initial Run

Testing is easy; run mvn test from the project root(tdd_demo).

mvn test

The output should include the following.

...
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.programming_grimoire.buy_sell_stock_iii.AppTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 s -- in com.programming_grimoire.buy_sell_stock_iii.AppTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
...

Testing is also a build process. It generates the target directory, and with that, a ton more files.

When the project was generated:

12 directories, 3 files

After mvn test:

32 directories, 11 files

We want to clean the project before the next test.

mvn clean

After mvn clean:

32 directories, 11 files

So running the tests is a two-motion sequence. Don’t worry; it becomes reflexive.

mvn clean
mvn test

The Problem Statement

The Following comes from Leetcode Problem 123: ''Best Time to Buy and Sell Stock III'' ¹

You are given an array prices where prices[i] is the price of a given stock on the i^th day. Find the maximum profit you can achieve. You may complete at most two transactions. Note: You may not engage in multiple transactions simultaneously (i.e., you must sell the stock before you buy again).

The description includes some information we'll use in the tutorial.

We're given Example 1 with an expected input, output, and an explanation.

Input: prices = [3,3,5,0,0,3,1,4]
Output: 6
Explanation: Buy on day 4 (price = 0) and sell on day 6 (price = 3), profit = 3-0 = 3. Then buy on day 7 (price = 1) and sell on day 8 (price = 4), profit = 4-1 = 3.

The description also promises the following constraints.

1 <= prices.length <= 10^5
0 <= prices[i] <= 10^5

Leetcode provides the following stub for Java users.

class Solution {
   public int maxProfit(int[] prices) {

   }
}

All of this information is used in the tutorial.

The TDD Cycle

Minimum Test Case

Red

We'll need to construct some scaffolding before writing the first test.

Since the class name in Leetcode’s stub is Solution, there should be a SolutionTest.

touch src/test/java/com/programming_grimoire/buy_sell_stock_iii/SolutionTest.java

SolutionTest should be a part of the package buy_sell_stock_iii.

package com.programming_grimoire.buy_sell_stock_iii;

SolutionTest also requires jUnit imports or to actually, you know, run the tests.

import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;

Per Java convention, the class name is SolutionTest just like the file name.

public class SolutionTest extends TestCase {

The same is true for the constructor.

public SolutionTest( String testName )
{
    super( testName );
}

The class for SolutionTest should be passed to the convenience constructor, so test cases will be added automatically added to the suite. ⁵

public static Test suite()
  {
      return new TestSuite( SolutionTest.class );
  }

Using the convenience constructor forgoes the need to manually add test names to the suite.

public static Test suite() {
   TestSuite suite= new TestSuite();
   suite.addTest(new SolutionTest("testMinimumInput"));
   suite.addTest(new SolutionTest("testArrayOfTwo"));
   ...

Once the initial scaffolding is set up, the minimal failing test can be written and run.

According to the description, an input array may be of length of one.

1 <= prices.length <= 10^5

A profit isn't possible in this case. An investor may buy, but is unable to sell.

So for the sequence of 0, the expected answer is 0

int[] prices = new int[]{0};
int expectedResult = 0;

The full test case:

public void testMimimumInput()
     {
         int[] prices = new int[]{0};
         int expectedResult = 0;

         Solution s = new Solution();
         int actual = s.maxProfit(prices);

         assertEquals(expectedResult, actual);
     }

Clean the project and run the test suite to confirm the new test fails as expected. No implementation code has been written yet.

mvn clean
mvn test

...
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] .../tdd_demo/src/test/java/com/programming_grimoire/buy_sell_stock_iii/SolutionTest.java:[24,8] cannot find symbol
 symbol:   class Solution
 location: class com.programming_grimoire.buy_sell_stock_iii.SolutionTest
...

Green

This is the point to commit every sin imaginable; to rush ahead and implement, a Solution class that has a maxProfit instance method. T

The compilation error occurred because "Solution" doesn't exist in the project, so Solution needs to be created.

touch src/main/java/com/programming_grimoire/buy_sell_stock_iii/Solution.java

Like SolutionTest, Solution should be part of the buy_sell_stock_iii package.

package com.programming_grimoire.buy_sell_stock_iii;

...and export the proper class name.

class Solution {
#+end_example****

"Solution.java" also needs to have that maxProfit function which takes an integer array as an argument.

#+begin_example java
public int maxProfit(int[] prices) {
 return 0;
 }

The tests should run green now.

mvn clean
mvn test

...
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.programming_grimoire.buy_sell_stock_iii.AppTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 s -- in com.programming_grimoire.buy_sell_stock_iii.AppTest
[INFO] Running com.programming_grimoire.buy_sell_stock_iii.SolutionTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s -- in com.programming_grimoire.buy_sell_stock_iii.SolutionTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
...

There's no compilation errors nor test failures; the tests ran green.

Refactor

One test was written, but two tests ran.

[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

There’s now unnecessary work in the project.

tdd_demo
|---pom.xml
|---src
   |-- main
   |   |-- java
   |       |-- com
   |  |-- programming_grimoire
   |               |-- buy_sell_stock_iii
   |                   |-- App.java
   |                   |-- Solution.java
   |-- test
       |-- java
           |-- com
               |-- programming_grimoire
                   |-- buy_sell_stock_iii
                       |-- AppTest.java
                       |-- SolutionTest.java

12 directories, 6 files
#+end_example***

Out damned spots.

#+begin_src bash
 rm src/main/java/com/programming_grimoire/buy_sell_stock_iii/App.java
 rm src/test/java/com/programming_grimoire/buy_sell_stock_iii/AppTest.java
#+end_src

It seems trivial, but verify the tests still pass.
Unit tests like this need to be cheap to run in order to facilitate the “red, green, refactor” rhythm.

#+begin_example bash
mvn clean
mvn test

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.programming_grimoire.buy_sell_stock_iii.SolutionTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 s -- in com.programming_grimoire.buy_sell_stock_iii.SolutionTest

Cool! Now break it again.

Array of Length Two

Red

The answer for all sequences of length one is the same, so let’s expand the input size a little. It takes two days to make a transaction. In the case of a sequence 5,7, The investor would buy 5, then sell 7. The expected answer is 2.

int[] prices = new int[]{5, 7};
int expectedResult = 2;

The test case:

public void testArrayOfLengthTwo(){
     <<case-of-two>>

      Solution s = new Solution();
      int actual = s.maxProfit(prices);

    assertEquals(expectedResult, actual);
  }

The existing implementation is a hard coded return 0;, so the above test should fail.

...
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.programming_grimoire.buy_sell_stock_iii.SolutionTest
[ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.012 s <<< FAILURE! -- in com.programming_grimoire.buy_sell_stock_iii.SolutionTest
...
[ERROR] Failures:
[ERROR]   com.programming_grimoire.buy_sell_stock_iii.SolutionTest#testInputOfTwo AssertionFailedError expected:<2> but was:<0>
...

expected<2> but was:<0>: those are the droids we were looking for.

Green

Determining return values based on array length is a fast way to pass the existing tests. If the sequence is one day long, the investor can’t sell, and no transaction is possible.

if (prices.length == 1){
      return 0;

Otherwise, the investor can buy on the first day and sell on the second.

}else{
    return prices[1] - prices[0];
}

In the current universe of two tests, that implementation is correct.

...
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
...

Refactor

There's now duplication in the test suite.

 public void testMimimumInput()
 {
      int[] prices = new int[]{0};
      int expectedResult = 0;

      Solution s = new Solution();
      int actual = s.maxProfit(prices);

      assertEquals(expectedResult, actual);
 }

 public void testArrayOfLengthTwo()
 {
    int[] prices = new int[]{5, 7};
    int expectedResult = 2;

    Solution s = new Solution();
    int actual = s.maxProfit(prices);

    assertEquals(expectedResult, actual);
}

Specifically, there's a repeating pattern in instantiating a class and calling maxProfit every time to test an expected input and output..

Solution s = new Solution();
int actual = s.maxProfit(prices);

assertEquals(expectedResult, actual);

That functionality can be extracted to it's own method.

private void assertMaxProfit(int[] prices, int expected){
     Solution s = new Solution();
     int actual = s.maxProfit(prices);
     assertEquals(expected, actual);
}

That compacts each test case.

public void testMimimumInput()
   {
        int[] prices = new int[]{0};
        int expected = 0;
        assertMaxProfit(prices, expected);
   }

In turn, the test document reads a little cleaner.

 package com.programming_grimoire.buy_sell_stock_iii;

import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;

public class SolutionTest extends TestCase {

  public SolutionTest( String testName )
  {
    super( testName );
  }

  public static Test suite()
  {
       return new TestSuite( SolutionTest.class );
  }

  public void testMimimumInput()
  {
       int[] prices = new int[]{0};
       int expected = 0;
       assertMaxProfit(prices, expected);
  }

  public void testArrayOfLengthTwo()
  {
     int[] prices = new int[]{5, 7};
     int expected = 2;
     assertMaxProfit(prices, expected);
  }
   private void assertMaxProfit(int[] prices, int expected){
        Solution s = new Solution();
        int actual = s.maxProfit(prices);
        assertEquals(expected, actual);
   }
}

Test to confirm the refactor of the test doesn't change anything.

mvn clean
mvn test

...
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
...

Think of it like carrying an umbrella. It always seems to rain when you don’t have the umbrella with you.

Array of Length Two, Non-Increasing

Red

;;; This is a functional code block, don't touch. ;; Resume live text.

What if prices don't go up? For the sequence 9,5, the answer would be 0 because the investor would not walk away having lost 4 of whatever it is they're buying and selling.

public void testArrayOfLengthTwoNoProfit()
{
    int[] prices = new int[]{9, 5};
    int expected = 0;
    assertMaxProfit(prices, expected);
}

Does it break as expected?

...
[ERROR] com.programming_grimoire.buy_sell_stock_iii.SolutionTest.testArrayOfLengthTwoNoProfit -- Time elapsed: 0 s <<< FAILURE!
junit.framework.AssertionFailedError: expected:<0> but was:<-4>
...

Yes. The current implementation returns -4 instead of 0.

Green

The logic can be updated: if the sequence length is two and the second price is larger, then return the difference.

if (prices.length == 2 && prices[1] > prices[0]){
    return prices[1] - prices[0];

For all other cases, the answer is 0.

else{
    return 0;
}

Confirm it passes.

...
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
...

Refactor

There's duplication in the code; prices[0] and prices[1] are indexed twice.

The problem can be rephrased. The first and second elements are also the first and last elements.

int firstIndex = 0;
int lastIndex = prices.length-1;

We still obtain the difference.

int difference = prices[lastIndex] - prices[firstIndex];

In a sequence of one difference is 0 because it’s one element minus itself. If the difference is negative, no profit is possible. Otherwise the difference is the answer.

return difference < 0 ? 0 : difference;

That sounds flashy. Let's check to confirm it didn't break anything.

...
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
...

Array of Size Three

Red

The solution is perfectly fine as long as the optimum profit is gained by selling on the last day. However, the sequence 1, 3, 2 should have a profit of 2, not 1. The investor would know that they should sell early.

public void testArrayOfLengthThree()
{
    int[] prices = new int[]{1,3,2};
    int expected = 2;
    assertMaxProfit(prices, expected);
}

Smash it up.

...
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   com.programming_grimoire.buy_sell_stock_iii.SolutionTest#testArrayOfLengthThree AssertionFailedError expected:<2> but was:<1>
...

Green

At this state, the investor may investigate every possible buy and sell date, and track which profit from those potential transactions is the largest. Before any work's done, that maximum profit is 0.

int maxProfit = 0;

Every possible combination can be investigated by cycling through the possible indices i (for a possible purchase) and j (for a possible sale), such that j is in bounds for prices and i is less than j.

for (int j=1; j< prices.length; j++){
    for (int i=0; i< j; i++){

At this point, the programmer isn't optimizing, just committing every sin imaginable to get to green. As before, a possible profit is identified by calculating a difference.

int difference = prices[j] - prices[i];

If the difference is more than the maximum profit, then a new maximum profit has been determined.

if (difference > maxProfit){
    maxProfit = difference;
    }

}
}

The answer is the end value of the maximum profit.

return maxProfit;

It's faster to write than describe.

public int maxProfit(int[] prices) {
   int maxProfit = 0;
   for (int j= 1; j < prices.length; j++){
       for (int i = 0; i < j; i++){
	    int difference = prices[j] - prices[i];
	    if (difference > maxProfit){
		maxProfit = difference;
           }
       }
   }
   return maxProfit;
 }

Even though it looks like it should work, confirm that it does.

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.programming_grimoire.buy_sell_stock_iii.SolutionTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 s -- in com.programming_grimoire.buy_sell_stock_iii.SolutionTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.522 s
[INFO] Finished at: 2026-09-03T22:23:28-05:00
[INFO] ------------------------------------------------------------------------

Refactor

The nested loop yields a time complexity of O(n^2).That’s gonna barf up a brick once Leetcode scales up the input sizes.

Profit can be decomposed into terms of gain and loss.

\begin{equation} profit=gain-loss \end{equation}

These are now the factors of interest to the investor at each point in the traversal. At the first element of the sequence, were the investor to sell now they'd earn nothing because they have nothing. So the initial gain is 0.

int gain = 0;

Were the investor to buy the first element in the sequence they'd just lose that amount of money.So the initial loss is the first price in the sequence.

int loss = prices[0];

With that in mind, the investor checks each additional term in the sequence after the first to see if they can get a better deal.

for (int i = 1; i < prices.length; i++) {
  int currentPrice = prices[i];

At each price, the investor asks two questions: Will buying at this price lower my loss? and Will selling at this price maximize my gain?.

If buying now lowers the loss, then this is current best buying price.

if (currentPrice < loss ){
  loss = currentPrice;
}

If selling now raises the gain, then this is current best selling price.

int net = currentPrice - loss;
if (net > gain){
  gain = net;
}

After traversal has been completed, the investor has determined their maximum possible gain.

}
return gain;

All together, the implementation is just one flat loop, O(n).

int loss = prices[0];
for (int i = 1; i < prices.length; i++) {
  int currentPrice = prices[i];
if (currentPrice < loss ){
  loss = currentPrice;
}
int net = currentPrice - loss;
if (net > gain){
  gain = net;
}
}
return gain;

You know the drill.

... [INFO] ------------------------------------------------------- [INFO] T E S T S [INFO] ------------------------------------------------------- [INFO] Running com.programming_grimoire.buy_sell_stock_iii.SolutionTest [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 s -- in com.programming_grimoire.buy_sell_stock_iii.SolutionTest [INFO] [INFO] Results: [INFO] [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 ... #+end_example

Two Transactions

Red

The Example from Leetcode’s problem description outlines a case with two transactions. The sequence 3,3,5,0,0,3,1,4 should give the answer 6.

public void testTwoTransactions()
{
    int[] prices = new int[]{3,3,5,0,0,3,1,4};
    int expected = 6;
    assertMaxProfit(prices, expected);
}

So far, we've only one transaction as been tracked. The description mentions a sum of up to two transactions, so the existing implementation should fail.

... [INFO] Results: [INFO] [ERROR] Failures: [ERROR] com.programming_grimoire.buy_sell_stock_iii.SolutionTest#testExampleOne AssertionFailedError expected:<6> but was:<4> [INFO] [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0 ... #+end_example

Green

For the sequence 3,3,5,0,0,3,1,4, the investor determined the first 0 was the best purchase and that the 4 was the best sale. That's perfectly reasonable if only one transaction is allowed.

price	loss	gain
3	3	0
3	3	0
5	3	2
0	0	2
0	0	2
3	0	3
1	0	3
4	0	4

It’s time to track two transactions.

The first transaction should look familiar. Like before, it’s tracking the potential gain and loss starting at the first item in the sequence.

int firstLoss=prices[0];
int firstGain=0;

The same is done for the second transaction.

int secondLoss = prices[0];
int secondGain = 0;

In the case for the non-increasing array, it didn't matter if the first index and the same index were the same item. If there's only one transaction, then the first transaction is the second transaction.

Initially, the solution looks similar to the one-transaction version. There's a traversal.

for (int i = 1; i < prices.length; i++) {
  int price = prices[i];

The logic for the first transaction is the same as before.

if (price < firstLoss ){
  firstLoss = price;
}

int firstNet = price - firstLoss;

if (firstNet > firstGain){
  firstGain = firstNet;
}

However the loss for the second transaction is offset by the highest possible gain from the first.

int offsetLoss = price - firstGain;

After that, the logic for the second transaction also updates and continues.

if (offsetLoss < secondLoss){
  secondLoss = offsetLoss;
}

int secondNet = price - secondLoss;

if (secondNet > secondGain){
   secondGain = secondNet;
}

At each price, the investor tracks the state of two potential gains and two potential losses. Note that the second loss is directly affected by the first gain.

price	first loss	first gain	second loss	second gain
3	3	0	3	0
3	3	0	3	0
5	3	2	3	2
0	0	2	-2	2
0	0	2	-2	2
3	0	3	-2	5
1	0	3	-2	5
4	0	4	-2	6

The final profit from the second traction is the answer.

}
return secondGain;

This iteration in full:

It sounds fancy, but does it work?

...
[INFO] Results:
[INFO]
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
...

Refactor

Once again there’s duplication. Those =gain=s and =loss=es are proliferating like rabbits.

I’ve referred to gain/loss pairs as /transaction/s, so conceptually, they already belong to an abstract data type. That verbal encoding can be formalized as a Transaction class.

class Transaction {
    int gain;
    int loss;

Duplicated logic can then be encapsulated as instance methods. For instance, both transactions initialize with the same values for gain and loss.

int gain = 0;
int loss = prices[0];

That can be soaked up by the constructor.

public Transaction(int initialPrice){
    this.gain = 0;
    this.loss = initialPrice;
}

Both transactions update their loss the same way.

if (price < loss ){
  loss  = price;
}

That can be a mutator.

public void optimizeLoss(int price){
     if (price < loss ){
       this.loss = price;
     }
}

The pattern for updating gains can also be encapuslated.

int net = price - loss;
     if (net > gain){
       gain = net;
     }

For lack of a better sounding signature, I’m going with optimizeLoss and optimizeGain.

public void optimizeGain(int price){
    int net = price - this.loss;
    if (net > this.gain){
        this.gain = net;
    }
}

Ordinarily, we'd go with one class per file, however there are a couple of factors that make this different. Leetcode’s environment is a one-document deal. Nobody wants to pull from multiple files to copy+pase a solution into a browser field. Following the established pattern, the programmer wants to motivate the need for a .java file by way of a failing test suite. Since Transaction class is subordinate to the maxProfit method, it can be set as a private nested class in Solution.

The full refactor is as follows:

Transaction firstTransaction = new Solution.Transaction(prices[0]);
Transaction secondTransaction = new Solution.Transaction(prices[0]);

for (int i =0; i< prices.length; i++){
    int price = prices[i];

    firstTransaction.optimizeLoss(price);
    firstTransaction.optimizeGain(price);

    secondTransaction.optimizeLoss(price - firstTransaction.gain);
    secondTransaction.optimizeGain(price);
}

return secondTransaction.gain;

package com.programming_grimoire.buy_sell_stock_iii;

class Solution {

  private class Transaction {
  private     int gain;
  private     int loss;

     public Transaction(int initialPrice){
         this.gain = 0;
         this.loss = initialPrice;
     }

     public void optimizeLoss(int price){
          if (price < loss ){
            this.loss = price;
          }
     }

     public void optimizeGain(int price){
         int net = price - this.loss;
         if (net > this.gain){
        this.gain = net;
         }
     }
   }

  public int maxProfit(int[] prices) {

    Transaction firstTransaction = new Solution.Transaction(prices[0]);
    Transaction secondTransaction = new Solution.Transaction(prices[0]);

    for (int i =0; i< prices.length; i++){
        int price = prices[i];

        firstTransaction.optimizeLoss(price);
        firstTransaction.optimizeGain(price);

        secondTransaction.optimizeLoss(price - firstTransaction.gain);
        secondTransaction.optimizeGain(price);
    }

    return secondTransaction.gain;
  }
}

Wax on. Wax off.

cd tdd_demo
mvn clean
mvn test

...
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.programming_grimoire.buy_sell_stock_iii.SolutionTest
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 s -- in com.programming_grimoire.buy_sell_stock_iii.SolutionTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
[INFO]
...

;;Functional code, do not change ;;Return to live text

Conclusion

Test-Driven Development is not a silver bullet⁶, however the constraints can be useful.

They force the programmer to confirm the system is failing as expected. If you're expecting a test assertion failure and receive a compilation error, congratulations. You've just caught a bug early.
They force the programmer to work on one darn thing at a time. That one darn thing can be anything from determining failure modes to defining a definite interface from a vague set of requirements.
They force the programmer to re-evaluate and rewrite what they check in. Writing code is writing, and writing is re-writing.

Hopefully you'll find some use as well.

https://leetcode.com/problems/best-time-to-buy-and-sell-stock-iii

Beck, Kent. Test-Driven Development By Example Addison-Wesley, September 2007

https://support.leetcode.com/hc/en-us/articles/360011833974-What-are-the-environments-for-the-programming-languages

⁴

https://maven.apache.org/

⁵

https://sources.debian.org/data/main/j/junit4/4.10-3/doc/cookstour/cookstour.htm

⁶

Brooks, Frederick P. (1986).

Ball-point Pens and Why I Became an Evil Wizard

2026-08-27T00:00:00+00:00

Text editors are like pens; I use my favorite and maintain a backup. With tools, a constant and reliable instrument can be clunky unpleasant to use. On the other hand, a tool with more positive affect is often more temperamental. It's also important not to place tool preference at the exclusion of common standards.

My analog text editor of choice is my Lamy fountain pen. It requires less pressure to write than a ball-point. Weighing 24 grams, it has a pleasant heft compared to a Pilot V7. Most disposable ball-points weigh under 20 grams. It's a refillable, maintainable environmentally friendly writing machine. Take care of a good fountain pen and it will take care of you forever.

Fountain pens will also run out of ink abruptly. I keep my pen in my pocket but a ball-point in my backpack. That means there's a beta mode available with a low-friction switch, just holster the Lamy and continue with pilot.

Plus, if someone needs to borrow a pen, I can give them my tractable, fungible ball-point. (todo, check usage) Fountain pens aren't in common use; not everybody's familiar with them. Hand a someone a ball-point and they'll write something down. Hand them a fountain pen and they'll pause as if they don't know how to operate the foreign object. In addition to avoiding friction from an adoption barrier I also want to protect my assets; there's also the possibility that someone might walk away with the pen I hand them.

My other text editor of choice is emacs. I'm having a blast. Org mode lets me manage my focus, and I can write the configs as a "literate programming" document. If the only application of literate programming is the emacs configs. Plus, emacs' arcane Lisp configurations make me feel like a wizard.

I learned vim first.

It's easy to keep a copy of vim on your system. First off, because it's very resource efficient, second because it's probably already there. Unix-like systems (including Linux, MacOs and Android) already come with vim installed.

It's also hard to learn. Vim uses keyboard shortcuts (or "motions") as the primary control mechanism. The motions get into your fingers, like piano scales or Street Fighter combos. After I die, I'll probably still be tapping :wq on the door of my coffin. Emacs also relies on keyboard motions, emacs and vim motions are wildly different.

On day 1 of using emacs, I could log in, but I couldn't exit out (C-c C-x by the way).

Fortunately, Emacs supports vim motions with the plugin "evil-mode".

Using vim mode on an editor is more than a personal convenience. By keeping the vim skill set alive, I have access to a consistent, , low-overhead backup text editor. Because of vim/vi's ubiquity and low profile, vim motions are a lingua franca of the terminal. This makes it much more likely for me to run into other vim users than Emacs users. In a collaborative workspace, it's impractical to maintain an editor that uses emacs-only motions; It's like handing a coworker a pen that they don't know how to use.

I use Emacs, which makes me a wizard. And I use it in evil mode which makes me an evil wizard. 🧙🏻

The Elements of Clean Code

2026-08-24T00:00:00+00:00

Simplicity is prerequisite for reliability. -- Edsger Dijkstra

Rage Bait

Let's take it as an axiom that most code sucks.¹ It's not just that it's buggy, it's messy, obscure and difficult to read. Stuff breaks. Requirements change. It's not enough for the code to run, somebody will have to edit this stuff.

Code that's easier to read, and therefore sucks less, is colloquially known as "clean code". The term shares a name with Robert Martin's book "Clean Code".

Periodically, people bring up the book and argue vehemently. I haven't seen so many nerds delight in expressing such seething hatred since "Batman and Robin" bombed in 1997.

The controversy reminds me of William Strunk's "The Elements of Style".

The Elements of Style

Like "Clean Code", "The Elements of Style" is a prescriptive manual on craftsmanship.² It has its own proponents and detractors.

There is little or no detectable bullshit in that book. (Of course, it's short; at eighty-five pages it's much shorter than this one.) I'll tell you right now that every aspiring writer should read The Elements of Style. Rule 17 in the chapter titled Principles of Composition is 'Omit needless words.' I will try to do that here. -- Stephen King

There are no rules, just tools. Let's see how these tools are useful.

Mapping

Each book presents endorses directness, clarity and brevity. Many of The Elements of Style"' principles of composition to "Clean Code"'s recommendations.

The Elements of Style	Clean Code
Use definite specific concrete language	Use Intention-Revealing Names
Omit Needless Words	Write small functions, don't repeat yourself
Express coordinate ideas in similar form	Use polymorphic objects that share a uniform interface

Examples

Prose

Revising text according to "The Elements of Style" can clear up a muddy passage. Here's an example.³

Macbeth was very ambitious. This led him to wish to become king of Scotland. The witches told him that this wish of his would come true. The king of Scotland at this time was Duncan. Encouraged by his wife, Macbeth murdered Duncan. He was thus enabled to succeed Duncan as king.

The revision delivers the same information.

Encouraged by his wife, Macbeth achieved his ambition and realized the prediction of the witches by murdering Duncan and becoming king of Scotland in his place.

We could call that "clean prose".

Code: The Generate Primes Example

The following GeneratePrimes examples use the Sieve of Eratosthenes to generate prime numbers.

Generate Primes

Here's the 'bad' version from "Clean Code". It's not as messy as code spotted in the wild, but it's still suitably mysterious. If you didn't write this code yourself, or don't remember writing it, you'd have to work to figure it out.

public class GeneratePrimes
   {
     /**
      * @param maxValue is the generation limit.
      */
     public static int[] generatePrimes(int maxValue)
     {
       if (maxValue >= 2) // the only valid case
       {
         // declarations
         int s = maxValue + 1; // size of array
         boolean[] f = new boolean[s];
         int i;
         // initialize array to true.
         for (i = 0; i < s; i++)
           f[i] = true;
         // get rid of known non-primes
         f[0] = f[1] = false;
         // sieve
         int j;
         for (i = 2; i < Math.sqrt(s) + 1; i++)
         {
           if (f[i]) // if i is uncrossed, cross its multiples.
           {
             for (j = 2 * i; j < s; j += i)
               f[j] = false; // multiple is not prime
           }
         }
         // how many primes are there?
         int count = 0;
         for (i = 0; i < s; i++)
                 if (f[i])
             count++; // bump count.
         }
         int[] primes = new int[count];
         // move the primes into the result
         for (i = 0, j = 0; i < s; i++)
         {
           if (f[i])  // if prime
             primes[j++] = i;
         }
           return primes;  // return the primes
       }
       else // maxValue < 2
         return new int[0]; // return null array if bad input.
     }
   }

Without the comments, it's less intelligible.

public class GeneratePrimes
   {
     public static int[] generatePrimes(int maxValue)
     {
       if (maxValue >= 2)
       {
         int s = maxValue + 1;
         boolean[] f = new boolean[s];
         int i;
         for (i = 0; i < s; i++)
           f[i] = true;
         f[0] = f[1] = false;
         int j;
         for (i = 2; i < Math.sqrt(s) + 1; i++)
         {
           if (f[i])
           {
             for (j = 2 * i; j < s; j += i)
               f[j] = false;
           }
         }
         int count = 0;
         for (i = 0; i < s; i++)
                 if (f[i])
             count++;
         }
         int[] primes = new int[count];
         for (i = 0, j = 0; i < s; i++)
         {
           if (f[i])
             primes[j++] = i;
         }
    return primes;
       }
       else
         return new int[0];
     }
   }

Refactored

Here's Robert Martin's refactor.

public class PrimeGenerator
   {
       private static boolean[] crossedOut;
       private static int[] result;

       public static int[] generatePrimes(int maxValue)
     {
       if (maxValue < 2)
         return new int[0];
       else
       {
         uncrossIntegersUpTo(maxValue);
         crossOutMultiples();
         putUncrossedIntegersIntoResult();
         return result;
       }
     }

      private static void uncrossIntegersUpTo(int maxValue)
     {
       crossedOut = new boolean[maxValue + 1];
       for (int i = 2; i < crossedOut.length; i++)
         crossedOut[i] = false;
     }

      private static void crossOutMultiples()
     {
       int limit = determineIterationLimit();
       for (int i = 2; i <= limit; i++)
         if (notCrossed(i))
           crossOutMultiplesOf(i);
     }

      private static int determineIterationLimit()
     {
       // Every multiple in the array has a prime factor that
       // is less than or equal to the root of the array size,
       // so we don’t have to cross out multiples of numbers
       // larger than that root.
       double iterationLimit = Math.sqrt(crossedOut.length);
       return (int) iterationLimit;
     }

      private static void crossOutMultiplesOf(int i)
     {
       for (int multiple = 2*i; multiple < crossedOut.length; multiple += i)
         crossedOut[multiple] = true;
     }

    private static boolean notCrossed(int i)
     {
       return crossedOut[i] == false;
     }


     private static void putUncrossedIntegersIntoResult()
     {
       result = new int[numberOfUncrossedIntegers()];
       for (int j = 0, i = 2; i < crossedOut.length; i++)
         if (notCrossed(i))
           result[j++] = i;
     }

    private static int numberOfUncrossedIntegers()
     {
       int count = 0;
       for (int i = 2; i < crossedOut.length; i++)
         if (notCrossed(i))
           count++;
    return count;
     }

    private static int numberOfUncrossedIntegers()
     {
       int count = 0;
       for (int i = 2; i < crossedOut.length; i++)
         if (notCrossed(i))
           count++;
       return count;
     }
   }

This style of refactoring has caused a bit a rift in code reviews; it adds more lines of code than it takes out. On paper, this doesn't "omit needless words".

Programmers won't read code on paper; you're not even reading this on paper. An Integrated Development Environment (IDE) such as VS Code will usually fold blocks of code. The initial view would be something like the following.

public class PrimeGenerator
   {
       private static boolean[] crossedOut;
       private static int[] result;

       public static int[] generatePrimes(int maxValue)
     {
       if (maxValue < 2)
         return new int[0];
       else
       {
         uncrossIntegersUpTo(maxValue);
         crossOutMultiples();
         putUncrossedIntegersIntoResult();
         return result;
       }
     }

   ...

   }

IDEs will also hyperlink function invocations to their declarations, so the "Clean Code" style turns source code into a Wiki.

...
private static void crossOutMultiplesOf(int i)
  {
    for (int multiple = 2*i; multiple < crossedOut.length; multiple += i)
      crossedOut[multiple] = true;
  }
...

Mapping Revisited

When William Strunk urged writers to "make the paragraph the unit of composition", he predated "Uncle Bob's formatting rules" by almost 100 years.⁴

If the subject on which you are writing is of slight extent, or if you intend to treat it very briefly, there may be no need of subdividing it into topics. Thus a brief description, a brief summary of a literary work, a brief account of a single incident, a narrative merely outlining an action, the setting forth of a single idea, any one of these is best written in a single paragraph. After the paragraph has been written, examine it to see whether subdivision will not improve it.

Ordinarily, however, a subject requires subdivision into topics, each of which should be made the subject of a paragraph. The object of treating each topic in a paragraph by itself is, of course, to aid the reader. The beginning of each paragraph is a signal to him that a new step in the development of the subject has been reached.

Conclusion

"Clean Code" has shortcomings (shoe-horning Test-Driven Development into a syntax formatting guide feels like bringing up politics at Thanksgiving dinner), but publicly banning it or slamming it⁵ seems unnecessarily theatrical.

It's one way to build software, not the only way.

William Strunk and Robert Martin are similar; everything they say is opinion by default. That's true of all writers.

To the market of hot takes, I submit my recommendation for "Elements of Style" over "Clean Code". It imparts many of the same sentiments in fewer pages. Use it if it works for you.

Sadly, this makes it overwhelmingly likely that my code sucks. All men are mortal. Socrates is a man. Therefore...

You can read it for free. The first edition is public domain and can be accessed through Project Gutenberg.

Omit needless words, the Elements of Style, 1918

⁴

"Uncle Bob" is a poorly chosen nickname. When a complete stranger asks me to call him "Uncle" anything, I politely refuse. Then I call the cops.

⁵

Except for that "Uncle" shit.

The Secret of Org

2026-08-17T00:00:00+00:00

I've recently adopted emacs and discovered the delights of Org Mode. I'd say it even has a positive cognitive effect. To get there, it's a bit of a journey, which winds through working method superstitions, text editor wars and comparisons to Don Bluth movies.

So how did I get started with emacs? I wanted to try Literate Programming (LP). It's a "programming as essay writing" paradigm Donald Knuth proposed in 1984. The format inverts the relation of comments and code. Source documents for the programmer are expository prose sections punctuated by blocks of executable code. The source document is transpired in two ways: It's 'woven' into documentation, and also 'tangled' into code recognizable by the interpreter or compiler.

In his interview in the book Coders at Work, Knuth effused about his home-rolled paradigm

What I try to work on is units that correspond to the way I have it in my head, rather than the way a logician might want it to be in some formal system. My programs are supposed to match my intuition more than somebody else’s rigid framework.

Of course, eventually it has to go into a computer, which is rigid, which has its precise rules of understanding. But to me the idea of the right kind of program is something that matches the way I think as closely as possible rather than something that matches the machine as closely as possible. I have to find the way to do the conversion, but my source text tries to stay closer to my brain than to the machine.

Coding by intuition is an out-there idea. I don't mean "vibe coding" where you argue with Claude code for three hours and transform into a reverse centaur. I mean whatever mystical semi-transcendent state the inventor of the Potrzebie System was talking about. Will sampling some of this special blend expand my mind and make me a better programmer?

I don't know, but it seemed like an idea too crazy not to try.

The closest thing to a generalizable implementation of LP is emacs' Org Mode. Variants of Knuths's .web files transpile to C or Pascal. Computerized notebooks like Jupyter can replicate the work style, but they're bound to specific languages and use cases. Some poking around about LP brought me to Howard Abrams who confidently (perhaps suspiciously so?) asserts that cross-language literate programming can be done in Org Mode.

Org Mode is primarily a note-taking mode on steroids. The primary feature is the ability to represent information in a heiarcy (in this case, headers, sub-headers and nested lists) and slide those blocks around the tree with a minimum of fuss.

Org Mode plugins are available for other editor, but the necessary tangle relies on Org Babel.

I wasn't looking to write to-do lists, I was looking to program. It looked like for the purposes of this experiment, I'd need to install emacs.

Historically, I'm used to vim, emacs' ancient blood rival. Fans of these platforms get really passionate about the inherent values of their tools. I initially had picked up vim because I wanted to invest in learning an evergreen text editor, and didn't give it much thought after that. I felt a little guilty about breaking ranks.

Setting up emacs is exactly as fun as it sounds. The process entailed flagellation by configuration, pursuits of wild ornithoids without cause, false starts, and learning additional emacs commands on top of my vim motions.

If I was worried about betraying the holy cause of vim, I believe my suffering has sufficiently paid for my sins.

Rather than take a first experiment with a full-featured application,n I figured I'd test LP on configuring a blog with a framework I haven't used before. This blog is a statically generated site using zola.

The single source of truth for the zola configuration is an .org file so I can build the site via Literate Programming (My emacs configuration is also an .org file so I can adjust the emacs settings via Literate Programming ... turtles all the way down). Zola has a simple tutorial. Would I gain any insight by implementing it LP? The plan was to write it like a prose document: two drafts and a polish.

Draft one was "write everything down and make it work". I'd write down notes set the basic .html and .toml syntax in src blocks in the .org file. If a block of text or code was too large, I'd just set it under a header and fold it. I never touched zola before so there were conventions and jargon that made no sense, why where there documents formatted with '_**.md'? Why did some .toml describe site content and others describe some kind of information schema? What the heck were "sessions"? I wrote down all my musings, brain farts and questions and kept going.

Once the output worked, I revisited the big messy .org file to clean it up. Writing is rewriting. If there was any magic to LP, it would emerge from the second draft.

While sliding around fold-able blocks of text, I read over my ramblings about "sessions" and other zola conventions. I had my Secret of NIMH moment. Like the cartoon lab rat-turned-wizard recalling his mental awakening....

I looked at the words on the cage, and I understood them

Looking over my notes from earlier, I found I could answer these questions... explain them in my own words, and leave my explanation there while the rationale was still fresh. I used the .org file as a living scratch-pad, and that expanded my context window. My world exploded; I knew what the hell I was doing.

The easy reshuffling Org Mode facilitates is awesome, but the jury's still out on Literate Programming. It's extremely unlikely to be adopted as a standard in developing commercial applications. Most programmers don't want to write technical essays. Also, Donald Knuth has many outstanding traits, but "speed" isn't one of them; TeX was a 10 year side project. Using emacs' org mode for LP means learning a whole new meta-syntax for a language-agnostic framework. Most languages that have their own conventions for comments and macros.

Given some more shakedown time, Literate Programming could prove to be well worth the hassle. If more work at the top means fewer bugs later, that's added value. If the woven-in documentation is clear, usable and superior to the (often-skipped) annotation style, that's added value. If the process produces a very clear understanding with the programmer, that's added value.

So far I got one out of three.

I find org mode to primarily be an attention management system useful for arranging and internalizing ideas. When working "straight ahead" in that stream-of-consciousness mode, you can add headers to massive walls of text (stack traces from a src'd out shell command) and fold them from view. So you can expand your context window when troubleshooting command-line issues. Most importantly, when you revise your notes, you farm out the insights from the free-form brain dumps.

I can't say I'm an emacs convert, but it's worth getting beat into the gang to try out Org Mode.