DEV Community: Enno Rehling (恩諾)

Testing Laravel JSON requests

Enno Rehling (恩諾) — Tue, 27 Jan 2026 09:23:38 +0000

Chased a stupid problem all day today. Long story short: I had a simple Laravel controller that was trying to just echo back the inputs from a JSON request body. It's not enough to write a test like the following.

Wrong Code:

class MyTest extends TestCase {
  function test_example() {
    $this->withHeaders([
      'Accept' => 'application/json',
      'Content-Type' => 'application/json',
    ])->post('echo', ['foo' => 'bar'])->assertJson(['foo' => 'bar']);
  }
}

The controller tries to read $request->all(), which is empty! That's because of how the Laravel test framework constructs request objects. It doesn't care that I provided those headers to indicate that there was a JSON body to draw from. You have to use postJson instead of post for that, and then you don't need those headers, either.

Correct:

  function test_example() {
    $this->postJson('echo', ['foo' => 'bar'])->assertJson(['foo' => 'bar']);
  }

The same is true for patch vs. patchJson. So somehow, I've been using the wrong method all this time, and it's never been a problem? I'm shocked and confused.

Puzzle of the day: VS Code and CMAKE_TOOLCHAIN_FILE

Enno Rehling (恩諾) — Sat, 19 Mar 2022 11:50:24 +0000

This is one of those problems that I've now solved from scratch at least twice, and never gives good Google result, do it's time I write a post, if only for myself.

My situation is as follows: I'm running VS Code on a Windows host to build a Linux program with WSL2, or other remote connection (i.e. SSH to a remote machine). My build tool of choice is CMake, and I have the CMake extension installed.

Trying to build my project gives me this error:

[proc] Executing command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/x86_64-linux-gnu-gcc-10 -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/x86_64-linux-gnu-g++-10 -S/home/enno/echeck -B/home/enno/echeck/build -G "Unix Makefiles"
[cmake] CMake Error at /usr/share/cmake-3.18/Modules/CMakeDetermineSystem.cmake:99 (message):
[cmake]   Could not find toolchain file: C:/vcpkg/scripts/buildsystems/vcpkg.cmake

Somehow, there is a CMAKE_TOOLCHAIN_FILE argument being passed to cmake, and it contains a path on my Windows filesystem (this project also compiles on Windows, using vcpkg for its find_package dependencies). Of course this can't work, I'm using a gcc toolchain on Linux. Where does this come from?

The answer turned out to be that the settings.json file in %APPDATA%\Code\User on my Windows host contained this nugget:

    "cmake.configureArgs": [
        "-DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake"
    ],

I must have set this at some point, trying to use VS Code to build on Windows, and for reasons, VS Code applies it to all my CMake builds, even remote builds. So, after I deleted that entry from the settings.json file and deleted the generated CMakeCache.txt, I can now build my project! And next time this happens, I hope Google will point me to this post.

List Formatting in C

Enno Rehling (恩諾) — Sat, 21 Sep 2019 19:18:20 +0000

Today I needed to format a list of words in C, and ended up writing my own list formatter, which was rather satisfying (I like fidgety string manipulation). The goal was this: given a list of words like {"apple", "banana", "mango"}, create a string like "apple, banana, and mango". At first glance, this is simple: We step through the list, append each word to the result with a trailing comma, and when we're appending the final word, prefix it with " and ".

char *format_list(int argc, const char **argv, char *output, const char *and) {
  output[0] = '\0';
  for (int i = 0; i != argc; ++i) {
    strcat(output, argv[i]);
    strcat(output, ", ");
    if (argc == i + 2) {
      strcat(output, and);
      strcat(output, " ");
    }
  }
  return output;
}

void print_fruit(void) {
    const char * fruit[] = {"apple", "banana", "mango"};
    char buffer[1024];
    puts(format_list, 3, fruit, buffer, "and");
}

WARNING: This function does no bounds checking, so the output buffer needs to have enough space for the resulting string. This is bad function design, and adding the necessary checking is not hard, but would make it harder to get the point across that this code is really trivial.

However, I needed my solution to work in other languages. We could use gettext to translate the inputs and the word "and", translate the word into a locale-dependent substitute, like this:

void print_fruit(void) {
    const char * fruit[3];
    char buffer[1024];
    fruit[0] = gettext("apple");
    fruit[1] = gettext("banana");
    fruit[2] = gettext("mango");
    puts(format_list, 3, fruit, buffer, gettext("and"));
}

This way (with the correct .po file and libgettext) we get "Apfel, Banane, und Mango" if we're using a German locale. There's a problem with that: German does not use an oxford comma. And other languages that I don't speak don't write lists with the same rules at all. Some put the and at the start (think "apple and banana, mango"). What we need is more than just the "and" to encapsulate all those rules, without writing a separate function for each language.

Cribbing inspiration from the icu4j library, this is the function I came up with:

https://github.com/ennorehling/clibs/blob/master/format.c#L29

I'm not including the entire file, since with the bounds checking, it gets rather long, but it does the trick, and is customizable by a set of patterns:

list of two words (English: "{0} and {1}")
start of a list with 3 or more elements (English: "{0}, {1}")
middle of a list with 3 or more elements (English: "{0}, {1}")
end of a list with 3 or more elements (English: "{0}, and {1}")

If you don't use an oxford comma (I won't judge you), then that last string should be "{0} and {1}".

Incidentally, this is the first time I've ever used goto in C, and I apologize to Ed Dijkstra and all the computer science teachers who told me, repeatedly, to never do that, ever. Well, I broke the law, and I regret nothing!