Forem: Philip Weinke

Colocating Tests and Production Code in PHP(Unit)

Philip Weinke — Tue, 22 Nov 2022 07:43:57 +0000

Colocating tests and production code is the default in some programming languages and has become the de facto standard in others. I have to admit that while I liked it in Go and TypeScript, I always felt a little queasy about doing it in PHP. I couldn't really name it; it was more a sense of "it doesn't feel right". Of course, it turned out to be just a bullshit bias, because it works just as well in PHP as it does in other languages. No matter which language, the benefits are the same:

You see at first glance if there are tests for a piece of code
You don't have to navigate as much anymore
You don't have to maintain parallel structures in source and test directories

Let's give it a try, shall we?

Migrating a simple project

Take this setup with test and production code in parallel structures and a single test suite:

src/
└── MyProject
    ├── MyClass.php
    └── MyOtherClass.php
tests/
└── MyProject
    ├── MyClassTest.php
    └── MyOtherClassTest.php

<testsuites>  
    <testsuite name="default">  
        <directory>tests</directory>  
    </testsuite>
</testsuites>

The good news is that migration is as easy as dragging and dropping the MyProject directory from tests to src; at least if you're using PhpStorm. PhpStorm will take care of changing namespaces appropriately. If your editor of choice doesn't offer this kind of refactoring, search and replace will do as well.

src/
└── MyProject
    ├── MyClass.php
    ├── MyClassTest.php
    ├── MyOtherClass.php
    └── MyOtherClassTest.php

The last thing you need to do is point PHPUnit to the new location. Just change the directory from tests to src and you're ready to go:

<testsuites>  
    <testsuite name="default">  
        <directory>src</directory>  
    </testsuite>
</testsuites>

What about multiple test suites?

When there is more than a single test suite, things get a bit tricky. Let's take a look at this setup:

tests/
├── Integration
│   └── MyProject
│       └── MyClassTest.php
└── Unit
    └── MyProject
        └── MyOtherClassTest.php

<testsuites>  
    <testsuite name="integration">  
        <directory>tests/Integration</directory>  
    </testsuite>
    <testsuite name="unit">  
        <directory>tests/Unit</directory>  
    </testsuite>
</testsuites>

If we colocate them the same way we did in the first example, there's no way to determine which test belongs to which test suite. Here are two options to approach this problem.

Using suffixes

The first option is to change the suffix Test to either IntegrationTest or UnitTest. This allows a clear distinction to which suite a test belongs, although it's a bit clunky.

src
└── MyProject
    ├── MyClass.php
    ├── MyClassIntegrationTest.php
    ├── MyOtherClass.php
    └── MyOtherClassUnitTest.php

<testsuites>
    <testsuite name="integration">  
        <directory suffix="IntegrationTest.php">src</directory>  
    </testsuite>
    <testsuite name="unit">  
        <directory suffix="UnitTest.php">src</directory>  
    </testsuite>
</testsuites>

Using groups

The second options is to use the group annotation to categorize tests. Since groups and test suites are different things and a test suite in PHPUnit cannot be composed of groups, the configuration can be simplified to a single test suite. Just remember that you have to use the group option instead of the testsuite option when running tests (phpunit --group integration or phpunit --group unit).

/**
 * ...
 * @group integration
 */
final class MyClassTest extends TestCase
{
    // ...
}


/**
 * ...
 * @group unit
 */
final class MyOtherClassTest extends TestCase
{
    // ...
}

<testsuites>
    <testsuite name="default">  
        <directory>src</directory>  
    </testsuite>
</testsuites>

Tweaking PhpStorm

I was a little disappointed when I discovered that the files in my project window looked like this:

The test classes have the red/green arrow indicating a test, but I was hoping they would be highlighted as I was used to with jest tests. Fortunately, this is easy to customize.

Go to Preferences | Appearance & Behavior | Scopes and set up a new scope matching test classes (file:*Test.php):

Then add an element for the new scope and pick a color under Preferences | Appearance & Behavior | File Colors:

It should look something like this now:

Sweet!

Another thing you may want to tweak is the severity of certain inspections. I noticed warnings showing up that weren't there before. This is probably due to the way PhpStorm handles files based on what type of directory they're in (Preferences | Directories). Since we already have our new scope set up, we just have to change the severity under Preferences | Editor | Inspections to mute unwanted inspections.

That's it

That's all I have to say on this topic at the moment. I've been using this approach in my personal projects for over a year now, and introduced it at work about a month ago. So far, everyone likes it.

I wouldn't write a test for that

Philip Weinke — Mon, 04 Apr 2022 00:00:00 +0000

Last week, I was helping a colleague who was working on a small application. One component was responsible for sending data to a configured recipient. I suggested writing a test to verify that an email was actually sent containing the relevant data in the body. This led to the following discussion:

X: “What? No, I wouldn’t write a test for that.”
Me: “Why not?”
X: “Because we would be testing third-party code.”
Me: “No, we would be testing that our component does what it’s supposed to do.”
X: “Can’t we just mock the mail library?”
Me: “In that case, I’d rather not write a test. I really want to see that it happens.”
X: “I don’t know. It feels wrong.”
Me: “How would you verify that it actually sends the mail then?”
X: “Well, I already installed the mail library, wrote a little test script, spun up a mailhog, and checked that there was a mail in the inbox …”
Me: “… so you kind of did the test I’m suggesting. Manually. One time.”

I guess his approach isn’t that unusual. You write some code to figure out how a new library works, and when you’re confident enough, you integrate it. You save writing a test, because you use a third-party library that just works™. I’m sure it does, but still… I want to see proof.

As I stated in the discussion, it’s not about testing that library. It’s about that our code works as intended, no matter what the implementation looks like. If I upgrade the library to a new version, I want to be sure that it still works. If I switch to a different library, I want to be sure that it works the same as before. Maybe it’s just me, but I really like having that confidence.

So, next time you don’t want to write a test because it’s some lib that just works, plus you just checked it manually: give it a try and automate it anyway. It’s not that hard. (In our case, it was hard. We spent about an hour in some weird jest/javascript hell until the test passed. I really don’t know how people get shit done with javascript)

Advent of Haskell, Part 2

Philip Weinke — Tue, 22 Dec 2020 19:49:56 +0000

It's already been more than two weeks since I started my little Advent of Code + Haskell adventure. So it's time for a little update. Here's what I got done.

Day 2

Puzzle description

Regular expressions are often my first choice when I have to parse something. Like in this case, to get the values easily out of strings like 6-8 b: bbbnvbbb. How hard can that be? Harder than I thought. After spending quite some in the docs and repl I was close to giving up. But then I found an article that really helped. So, I finally got a working parse function that returns the four values of a given line as a list of strings:

parse :: String -> [String]
parse input = drop 1 (getAllTextSubmatches $ input =~ "(.+)-(.+) (.): (.+)" :: [String])

From there on things went smoothly.

Part 1: Just some range checking

policy1 min max char str = cnt >= min && cnt <= max
  where cnt = length (filter (==char) str)

Part 2: Just some good old XOR

charAt p str = if length str > p then str !! p else ' '

policy2 p1 p2 char str = (charAt (p1 - 1) str == char) /= (charAt (p2 - 1) str == char)

But wait. How do I pass the list of strings to the policy functions? I introduced a little helper that does all the destructuring, conversion and execution.

isValid policy [min, max, char, str] = policy (read min :: Int) (read max :: Int) (head char) str

Finally, plugging it all together:

validCount xs = length (filter (==True) xs)

solve input = do
  let pwData = map parse (lines input)

  putStrLn ("Part 1: " ++ (show (validCount (map (isValid policy1) pwData))))
  putStrLn ("Part 2: " ++ (show (validCount (map (isValid policy2) pwData))))

Full source on github

Day 3

Puzzle description

This one was really easy and there isn't much I have to say. The only thing I had to look up was how to do a modulo. The rest was pretty straight forward.

tree x map = if (map !! (x `mod` (length map))) == '#' then 1 else 0

traverseMap :: [String] -> Int -> Int -> Int -> Int
traverseMap [] px right down = 0
traverseMap (x:xs) px right down = tree px x + traverseMap (drop (down - 1) xs) (px + right) right down

solve input = do
  let traverse = traverseMap (lines input) 0

  putStrLn ("Part 1: " ++ (show (traverse 3 1)))
  putStrLn ("Part 2: " ++ (show ((traverse 1 1) * (traverse 3 1) * (traverse 5 1) * (traverse 7 1) * (traverse 1 2))))

Full source on github

Day 4

Puzzle description

In the solution for this puzzle I wrote in PHP I used multiple regexes. After my previous struggle with regexes in Haskell, I tried to avoid them this time.

I wanted to have a structure that could be used to solve both parts of the puzzle. A map seemed like a good fit for both, the passport data (field names and values) and the schema (field names and validator functions).

passportSchema = Map.fromList [
  ("byr", isBetween 1920 2002),
  ("iyr", isBetween 2010 2020),
  ("eyr", isBetween 2020 2030),
  ("hgt", isValidHeight),
  ("hcl", isHexColor),
  ("ecl", isEyeColor),
  ("pid", isPid)
  ]

isBetween and isEyeColor verify that a value is part of a given set using elem. isPid checks the string length and validates characters using a combination of all and isDigit. isHexColor is basically the same, except that it checks the characters using isHexDigit and that the string starts with #.

isBetween min max v = (read v :: Int) `elem` [min..max]

isEyeColor v = v `elem` ["amb", "blu", "brn", "gry", "grn", "hzl", "oth"]

isPid v = length v == 9 && all isDigit v

isHexColor v = hash == '#' && length values == 6 && all isHexDigit values
  where (hash:values) = v

Implementing isValidHeight was a little bit trickier.
The function splits the numeric value from the unit by using takeWhile/
dropWhile in combination with isDigit. Although this solution isn't as strict as a proper regex, it did the job for this puzzle.

isValidHeight v =
  let unit = dropWhile isDigit v
      value = takeWhile isDigit v
  in (unit == "cm" && between 150 193 value) || (unit == "in" && between 59 76 value)

To convert a single passport from the puzzle input to the map structure I use splitOneOf to split the fields by either space or newline. All fields will then be splitted into key/value pairs using splitOn and mapped to a tuple which is needed for Map.fromList.

toPassport input = Map.fromList (map (\x -> (head x, last x)) (map (splitOn ":") (splitOneOf " \n" input)))

Part 1: A passport is valid if it has at least all fields defined in the schema.

hasAllRequiredFields schema passport = length ((Map.keys schema) \\ (Map.keys passport)) == 0

Part 2: A passport is valid if all values can be validated. If a field is missing in a passport, the Nothing clause in the case expression will make sure that the validation result is False.

isFieldValid passport field isValid = case Map.lookup field passport of
  Nothing -> False
  Just x -> isValid x

allFieldsValid schema passport = Map.foldrWithKey (\field validator acc -> acc && (isFieldValid passport field validator)) True schema

Applying it to all passports and counting the results:

countValid l = length (filter (==True) l)

solve :: String -> IO ()
solve input = do
  let passports = map toPassport (splitOn "\n\n" input)

  putStrLn ("Part 1: " ++ (show (countValid (map (hasAllRequiredFields passportSchema) passports))))
  putStrLn ("Part 2: " ++ (show (countValid (map (allFieldsValid passportSchema) passports))))

Full source on github

Day 5

Puzzle description

This one's puzzle input is just a bunch of binary strings in disguise. No fancy stuff needed. Just folding it down bit by bit.

charToBit x | x `elem` "FL" = 0 | x `elem` "BR" = 1

seatId input = foldl (\acc x -> acc * 2 + (charToBit x)) 0 input

Part 1: The maximum function is all that's needed to find the highest seat number

Part 2: To find the empty seat, I filter down the list of seat ids to the one that has its next id missing, but the one after next exists. Adding one gives us the empty seat id.

emptySeat seatIds = (head (filter (\x -> ((x + 1) `notElem` seatIds) && ((x + 2) `elem` seatIds)) seatIds)) + 1

solve input = do
  let seatIds = map seatId (lines input)

  putStrLn ("Part 1: " ++ (show (maximum seatIds)))
  putStrLn ("Part 2: " ++ (show (emptySeat seatIds)))

Full source on github

Day 6

Puzzle description

Part 1: nub already returns the unique elements of a list. Only thing left to do: Removing everything that's not an alpha character using a filter so newlines doesn't count.

countAny group = length (nub (filter isAlpha group))

Part 2: I used foldl1 to build the intersection of all answers within a group.
foldl1 is just like foldl except that it starts with the first element in the accumulator already. Perfect for the job!

countAll group = length (foldl1 (\acc x -> acc `intersect` x) (lines group))

Nothing unexpected to see here

solve input = do
  let groups = splitOn "\n\n" input

  putStrLn ("Part 1: " ++ (show (sum (map countAny groups))))
  putStrLn ("Part 2: " ++ (show (sum (map countAll groups))))

Full source on github

That's it

Well, I really haven't gotten that far. It's not that I'm lazy - at least not that lazy. I'm still solving the puzzles every day in PHP but my plan to catch up with Haskell afterwards hasn't worked out that well. The advent isn't yet over, though. Let's see what I can squeeze into the last few days.

Is there something I did overly complicated or goofy? Let me know. I'm still a Haskell novice and looking to improve.

Approaching 100% code coverage in a healthy way

Philip Weinke — Sun, 06 Dec 2020 15:52:24 +0000

One question the always comes to my mind in the discussion about code coverage is: What does the percentage refer to, anyway? This is probably a stupid question. It seems to be common sense that it is the whole codebase. But does it really have to be?

What is the value of code coverage, again? I like how Martin Fowler puts it in his article on this topic:

Well it helps you find which bits of your code aren't being tested.

Finding these bits is easier when there are only few of them. And with that I mean: few in the coverage report. Your codebase may have a lot of untested bits and that's okay. There are things you shouldn't test, anyway¹. To get rid of the noise, you just have to follow a simple process:

For every untested bit, you have to decide: Is this testworthy? If it is, write tests (or at least acknowlege that you should write tests for it). If not, exclude it from the coverage analysis.

For some people this is cheating, but I'd rather call it focusing. I don't need to be reminded of code that I'll never write tests for. Working this way allows you to reach 100% without writing tests that provide no real value. But even if you don't, it leaves you with a better picture since you actively decided on whether something should be tested or not.

Personally, I do not see much value in testing stuff like getters/setters, generated code or simple data mapping. You, your project and/or team may have other standards and that's fine. ↩

Advent of Haskell: Trying to solve puzzles without knowing Haskell

Philip Weinke — Sat, 05 Dec 2020 15:10:10 +0000

This year is the first time that I participate in the Advent of Code. What I learned right on the first day was that some people would finish the whole puzzle while I was still sipping on my morning coffee reading the assignment. I like challenges but I don't know whether I can compete with what's going on in the leaderboard. So, I thought it might be a good idea to add a personal challenge to keep it fun. Functional programming is an area where I have quite a few knowledge gaps so that seemed like a perfect fit. When I think of functional programming, Haskell is always one of the first things that comes to my mind. That made the language choice easy: I'm learning Haskell.

Let's go

Here's my starting position:

I haven't written a single line of Haskell before.
I haven't even read much Haskell or any other purely functional code before.
I do know some FP concepts and I'm also trying to incorporate them into my work. But after all, I'm just an OOP guy.

I went back to solve the first puzzle again. Two days earlier I had already written the probably most imperative solution one could come up with.

$input = array_map(
    fn(string $input) => (int)$input,
    explode("\n", file_get_contents('input'))
);

for ($i = 0; $i < count($input); $i++) {
    for ($j = $i + 1; $j < count($input); $j++) {
        if ($input[$i] + $input[$j] === 2020) {
            printf("%d\n", $input[$i] * $input[$j]);
            break;
        }
    }
}

for ($i = 0; $i < count($input); $i++) {
    for ($j = $i + 1; $j < count($input); $j++) {
        for ($k = $j + 1; $k < count($input); $k++) {
            if ($input[$i] + $input[$j] + $input[$k] === 2020) {
                printf("%d\n", $input[$i] * $input[$j] * $input[$k]);
                break;
            }
        }
    }
}

The thing is: As inelegant as this code may be, I didn't had to think about it. I read the assignment and it just came out like it was some mechanical reflex. With Haskell, however, there was no way for me to solve it without thinking.

With a rough idea of "something with recursion" I skimmed through a few sections of Learn You a Haskell and jumped into the REPL to play around. After a bit of warming up I made a plan: Build a list of tuples that contain the sum and product of all possible combinations and filter for the right answer. That sounded like something I could get done. In the REPL, I was able to get some working single bits I needed to solve the whole thing. So, I started plugging it together.

For some reason, I tried to get the type signatures for all functions right when I switched from the REPL to the editor. I don't even know why. It turned out to be a bad idea. I spent a ridiculous amount of time messing around, getting errors that were precise and confusing at the same time. At some point I simply dropped all the type signatures and one half of the errors just went away. The other half was actually an error because I was mixing integers and tuples in one part. After fixing it and cleaning up a bit, I eventually ended with the following solution. A little bit proud that I made it, I committed the code and went to bed.

module Main where

toTuple x = (x, x)

listToTuple x = map toTuple x

combine a b = (fst a + fst b, snd a * snd b)

combineTwo [] = []
combineTwo (x:xs) = (map (combine x) xs) ++ combineTwo xs

combineThree [] = []
combineThree (x:xs) = (map (combine x) (combineTwo xs)) ++ combineThree xs

withSum x y = map snd (filter ((==x).fst) y)

main = do
  input <- getContents

  let numbers = map read (lines input) :: [Integer]

  print (withSum 2020 (combineTwo (listToTuple numbers)))
  print (withSum 2020 (combineThree (listToTuple numbers)))

Couldn't I do better?

The proudness only lasted until the next evening. Was this really the best I could come up with? I tried to simplify the code by eliminating all the tuple stuff and it worked well for the first part of the puzzle.

module Main where

value a b = if a + b == 2020 then a * b else 0

combineTwo [] = []
combineTwo (x:xs) = filter (/=0) (map (value x) xs) ++ combineTwo xs

main = do
  input <- getContents

  let numbers = map read (lines input) :: [Integer]

  print (combineTwo numbers)

But I couldn't wrap my head around how to get it done with a combination of three. I figured that I wanted to be able to build combinations of n of a given list, but I was unable to express it with my Haskell rookie knowledge. Obviously I couldn't do better (yet), so I gave up, searched the net and found a solution.

module Main where

import Data.List

combinations 0 lst = [[]]
combinations n lst = do
    (x:xs) <- tails lst
    rest   <- combinations (n-1) xs
    return $ x : rest

value x = if sum x == 2020 then product x else 0

findValue lst = filter (/=0) (map value lst)

main = do
  input <- getContents

  let numbers = map read (lines input) :: [Integer]

  print (findValue (combinations 2 numbers))
  print (findValue (combinations 3 numbers))

I like the result, although I have a feeling that there is still some room for improvement. But I've already spent hours on the first puzzle, so it's time to move on.

What's next?

I purposely started this adventure without studying any material before just to see how it goes. It went okay but I definitely noticed that I am lacking a proper foundation. Before moving on to the next puzzle, I'll spend at least some time actually reading - not just skimming - some introductory material.

As someone who does TDD all the time, it also feels weird to have no tests in place. I know that HUnit and Hspec exists, so I'll probably check one of them or both out soon.

About confidence, code, and tests

Philip Weinke — Sun, 01 Mar 2020 15:05:54 +0000

Whether you're reading a classic like "Test-driven Development by Example" by Kent Beck or a yet another article on medium. When it's about testing, there's always some talk about confidence. That made me think.

Can you be confident about your code when you don't have tests?

The question seems ridiculous. Of course, you can. Millions of developers out there are. At least I was. Well, I still am. But something has changed.

Although I'm a big advocate of TDD, I wasn't born like that. Actually, I came pretty late to the party. I've started coding as a kid about 30 years ago and have been working for the past 20 years as a professional. But it wasn't until 10 years ago that I got into automated testing. Given that, I wrote a lot of code without any tests and for sure felt confident in doing so.

Precisely because I wrote a lot of code, I was able to build confidence. With every year, with every project and with every mistake I grew experience and with it came confidence. But still, nowadays I rarely write anything that's not test-driven. When I do, it's usually a one-off job or prototype. And while some people claim that they have a hard time coming up with a test first (or at all), I get anxious when I don't.

Tests have taught me one thing: Even though I feel confident that I won't break anything, I will. It might not happen often, but when it does, the red bar will hit me unexpectedly. It's a funny little feeling when it happens that is hard to describe. But I'll try it anyway:

Imagine having deployed a new release to production. Your phone rings just a few minutes later. It's your client yelling about something that's broken. Adrenaline kicks in. While they are still explaining the issue you know exactly what is broken, and why it's broken, and you hate yourself because it's such an obvious thing. Well, maybe that's overly dramatic, but you get the idea.

Now take away all the bad elements and you're left with a harmless little "gotcha". The instant you see the red bar, you probably still know what's broken and why but it doesn't do any harm. You fix it and move on.

Let's get back to the original question. Can you be confident without tests? Of course, you can. But maybe you shouldn't. Reading about the percentage that automated tests may drop your defect rate is nice, but seeing that it actually does was a game-changer for me. There's a chance that I'm just a lousy programmer who is overly confident, but with TDD, I found something that works for me. Maybe you should give it a try, too.