DEV Community: dvallin

Test your React App with Context

dvallin — Wed, 15 Apr 2020 12:47:55 +0000

Have you ever struggled to test this little fetch() call or this window.location in your React App? The thing with those Web APIs is that you cannot mock them directly. Of course you can globally mock the fetch API during test setup like this or use an npm package to do the same thing. But what to do with the next fancy API? I say you can solve the problem much easier and end up with a cleaner architecture at the same time by wrapping the APIs into a React.Context.

First let us define a very thin wrapping layer of all APIs we need to use

export interface Api {
    fetch: typeof fetch
}

export const createApi: () => Api = () => ({ fetch })
export const mockedApi: () => Api = () => ({ fetch: jest.fn() })

You can create the Api in two ways. One in your production code with createApi and one in your tests with mockedApi. The problem is that you can't just invoke fetch() wherever you like anymore. You first have to retrieve the Api object from somewhere. If you call the createApi() method whenever you need the object, you still cannot replace the Api by a mock during testing. You need to somehow pass the object through your whole App and put it into the Props of all your Components. This is not very elegant and a lot of work!

Luckily, React comes with a solution. You can create a React.Context object, put your Api into it and consume this context wherever you need it.

I do not like to use my API directly from my Components, so I first create Service objects.

export interface Services {
    users: UsersService
    contacts: ContactsService
    rest: RestService
}
const createServices = (): Services => {
    const api = createApi()
    const contacts = new ContactsService(api)
    const rest = new RestService(api)
    const entities = new EntityService(api)
    return { contacts, rest, entities }
}

When testing these services you can easily wrap the Api and focus on the interaction with the Api. For a component to use these services you have to put them into a React.Context.

export const Services = React.createContext<Services | undefined>(undefined)

const AppWithContext = (): JSX.Element => (
    <Services.Provider value={createServices()}>
        <App />
    </Services.Provider>
)

This is exactly how you provide a Redux Store to your App. Let us write something very similar to redux's connect function.

export const injectServices = <P extends object>(
    WrappedComponent: React.ComponentType<P & Services>
): React.ComponentType<P> => props => (
    <Services.Consumer>
        {services => services && <WrappedComponent {...services} {...props} />}
    </Services.Consumer>
)

This function takes a Component that has some Props P & Services and returns a Component that has only Props P. You can easily use it like this

type Props = Services & OwnProps
export injectServices(
    (props: Props): JSX.Element => <></>
)

and you can even put a connected Component into this function.

export const dispatchToProps: (
    dispatch: Dispatch,
    props: Service & OwnProps
) => Callbacks = (dipatch, props) => ({
    onSave: () => dipatch(createActionUsingService(props))
})

export default injectServices(
    connect(
        stateToProps,
        dispatchToProps
    )(MyComponent)
)

Now you can use the services even in your mapping function, which is probably exactly where you want them.

If you like this post, why not have a look at one of my other (probably more light-hearted) posts. This post was sponsored by itemis AG. That's the place were I work and drink.

Of Dungeons, Dragons and SAT-Solvers

dvallin — Wed, 01 Apr 2020 13:13:11 +0000

I love to work on my roguelike game in my spare time. Of course there is no end in sight and it will probably not be playable for months or years to come. But on the way, I always encounter some interesting problems. Most of them can be easily solved with some monkey work, but a few call for logic programming and the sledgehammer that is MiniSat.

A graph embedding problem appears

Imagine you have procedurally generated a dungeon. So you basically generated a list of structures representing rooms of the dungeon and their connections (aka doors).

export type RoomId = number
export interface Room {
  id: RoomId
  connections: RoomId[]
}

Now you know that on the current level there should be some rooms filled with enemies and loot. There should also be a shop near the entrance. Next to the shop, a random encounter that gives a side quest. And a dragon that guards the treasure room.

You start building descriptions for each of these structures. And try to fit them randomly into your dungeon. At first it is easy. Just decide for each room, what kind of filling it needs. A room near the entrance: Shop! A room somewhere inside the dungeon: Throw a d20, add some enemies, et voilà full dungeon. But then you try to fit the dragon in your dungeon. Now you have to look out, that there is a treasure room next to the dragon. And the treasure room should have only one entrance. Oh, and there should be only one shop. And not more than eight rooms filled with enemies...
Your code is starting to become more and more tangled and complex.

Let us step back for a moment and think about the problem in more abstract terms. The dungeon represents a graph G. The nodes are rooms and the edges are the doors. The descriptions of room fillings are also a graph H. The nodes are individual room fillings (e.g. a dragon, a treasure room, some enemies) and the edges bind them together. An edge between a dragon node and a treasure room node represents the restriction that they are directly connected.

Now to fill the empty dungeon with interesting content you only have to find an embedding of H in G!

You shall not SAT

You might say that restating the problem with a graph does not solve anything. But it helps in viewing the problem as a mathematical one. At its core it is just the embedding problem and every additional rule adds restrictions on how this embedding should be done. So each rule reduces the pairs of nodes in H and G that are allowed in a correct embedding.

A possible way to solve this problem is to represent it as a boolean satisfiability problem. Yes this problem is NP-hard but there exist a lot of SAT-Solvers that can handle problems far larger than our little dungeon. The devs at meteor even packaged the famous MiniSat solver using Emscripten on npm so you can solve SAT-Problems inside your browser!

Now let us represent the problem in SAT using Typescript!

First we introduce variables. We need a variable for each possible pair of nodes and write a little function that gives each v in G and w in H a unique name.

function createLabel(v: number, w: number): string {
  return `${v}_${w}`
}

Now for the actual rules of the embedding. The first rule is that each node in H can only be mapped to one node in G. That means if we have one dragon in H there shall only be one dragon in G. And if we need ten random ruffian-filled rooms, we need to put ten nodes in H that represent that. As a logical expression this may look like this

C_{vw} \Rightarrow \bigwedge\limits_{i \neq v}^{v \in H} \lnot C_{iw}

Written out this means: "If v is mapped to w then for all nodes i (that are not v) there is no mapping from i to w". For a SAT Solver to understand this rule, we need to transform it into conjunctive normal form (CNF) first. Now with material implication

\lnot C_{vw} \lor [ \bigwedge\limits_{i \neq v}^{v \in H} \lnot C_{iw} ]

and with the law of distributivity

\bigwedge\limits_{i \neq v}^{v \in H} ( \lnot C_{iw} \lor \lnot C_{vw} )

we can reach CNF. If you look closely at the above formulas you might notice that there is a trivial solution that satisfies them. When all variables are false! The formula expresses at least once and we additionally assert

\bigwedge\limits^{v \in H} [ \bigvee^{w \in G} C_{vw} ]

that for each node in H there must be a mapping to a node in G to make it exactly one.

Luckily, the logic-solver package has already a bunch of helper functions to create common logical expressions and this one is exactlyOne(). That means there is no need to put any more math formulas in this post 🤓.

  // each w in H on exactly one v in G
  H.V.forEach(w => {
    const Cvw = G.V.map(v => createLabel(v, w))
    solver.require(exactlyOne(...Cvw))
  })

This looks simple enough and solving this problem by running solver.solve() will even yield a solution! After mapping the variable assignments back to the graph embedding you realize that each node in H is mapped to the exact same node in G. Which means that all enemies, shops and dragons are being put into the same room. That would mean no backtracking and yack shaving, and that is the whole point of dungeon crawling. So let us write an additional rule to achieve that!

  // each v in G can map to at most one w in W
  G.V.forEach(v => {
    const Cvw = H.V.map(w => createLabel(v, w))
    solver.require(atMostOne(...Cvw))
  })

This looks very similar to the rule we created above, except that we are now coming from nodes in G to nodes in H and use the atMostOne() helper (we already derived the formula above). Each room of our dungeon now has at most one room mapped to it from H. The solver will fill our dungeon and keep dragons separated from shopkeepers.

Still the dragon is not sitting next to the treasure room, because we have yet to use the edges of H! Let us try to put into code that the neighbourhoods in H are also mapped to G.

  // all neighbours in H are mapped to neighbours in G
  H.V.forEach(w => {
    G.V.forEach(v => {
      const Cvw = createLabel(v, w)
      H.E.forEach(e => {
        const j = traverseEdge(e, w)
        if (j !== undefined) {
          const Cij: string[] = []
          G.E.forEach(f => {
            const i = traverseEdge(f, v)
            if (i !== undefined) {
              Cij.push(createLabel(i, j))
            }
          })
          solver.require(or(not(Cvw), ...Cij))
        }
      })
    })
  })

There is a lot going on here. The first two forEach statements are just to select each possible mapping of node pairs v and w. We use a simple function traverseEdge to find neighbours of nodes. Then for each neighbour j of w in H we create a new restriction. Now we look at each neighbour i in G of v. And we can finally state that if there is a mapping from v to w there must be a mapping from i to j.

Oh, you can imagine the fun that went into testing that code!

Conclusion

I presented only the bare essentials of my room embedder and a lot is still missing. There is for example no concept of an entrance to the dungeon and how deep a room is inside of it. Also rooms might be too small for a dragon or not close enough to the shop. But we can always create new restrictions and modify existing ones to meet our changing needs.

We can refine the solution on multiple levels. The first way is just to add more rules to the problem and to modify the graphs accordingly. But we can also extend the graph nodes with labels, remove nodes from G or modify H. It may also be a good idea to randomize the order of the rooms in G. And a crucial one is to run multiple embedding phases. The first phase to add the must-haves of the level. Dragons, shops, treasures. With the second run you add additional content like side quests. And during the last passes you can add monsters and decorations that can fill the gaps between the more engaging and complex content.

I guess, you can take it from here. Or get inspired to consider some logic programming for your own problems.

I hope you had as much fun learning about SAT solvers as me writing down those formulas in latex. This post was sponsored by itemis AG. That's the place where I work and drink.

Little red failing test and other fables

dvallin — Tue, 31 Mar 2020 13:35:24 +0000

Instead of writing about my blogging habits during quarantine, I wrote some short fables about unit test methodology for you to read to your kids and/or cats.

The Hare and the Hedgehog

One Sunday morning about harvest time, just as the buckwheat was in bloom, the sun was shining brightly in heaven, the east wind was blowing warmly over the stupple-fields, the larks were singing in the air, the bees buzzing among the buckwheat, the people were all going in their Sunday clothes to church, and all creatures were happy, and the Hedgehog was happy too.

The Hedgehog took a walk in the field, to visit his databases and look after his unit tests. When the Hedgehog caught sight of the Hare, he bade him a friendly good morning. But the Hare, who was in his own way a distinguished gentleman, did not return the Hedgehog’s greeting, but said to him, “How do you happen to be running about here in the morning?” - “I am going for a stroll” said the Hedgehog. “A stroll!” said the Hare with a smile. “It seems to me that you might use your legs for a better purpose.” This answer made the Hedgehog furiously angry, “You seem to imagine you can do more with your legs than I with mine.” - “That is just what I do think,” said the Hare. “That can be put to a test,” said the Hedgehog. “I wager that if we run a race, I will outstrip you.” To that the Hare agreed willingly for he was very confident in his quickness.

The next day the Hedgehog reached the field where the Hare already waited for him. “Shall we start?” said the Hare. “Certainly,” said the Hedgehog. The hare counted, “Once, twice, thrice, and away!” and went of in a whirlwind down the field. The Hedgehog, however, only ran about three paces, and then he wrote a unit test, so he would not get lost in the high grass of the field. After another three paces, he stopped again to write another unit test. And so he went forth for quite some time. The Hare, however, must had been running in circles and to his disbelief met with the Hedgehog. “That cannot be done fairly,” he cried “I was ahead of you Hedgehog the whole time, I shall try to run even faster!” The Hare went of like the winds storm, so that he seemed to fly, but the Hedgehog did not change his pace.

The Hare must had been running in circles many times, but never reached the top of the field. When the sun was already setting, the Hedgehog found the Hare lying dead in the middle of the field. The Hedghog, however finished the race quite before afternoon.

The moral of this story, however, is, firstly, that no one, however great he may be, should permit himself to ignore test coverage for the sake of velocity.

The Wolf and the Seven Features

There once was a Wolf who had written a very efficient database layer for his use case. The database layer implemented all features that the Hare had demanded in his user story. Satisfied with himself the Wolf said: “I have implemented all seven features and I can see they are good. But still, I have to test them!” So he went forth and created a test data image for his use case. He added a row for when there are all piglets in wooden homes, and one row for when only one piglet is in a wooden home and the others are in a stone home. He added many more rows like this. And when he was finished he started to write his test. With a single test he covered all features at once! The Wolf said: “This is very elegant. I tested all seven features in one big gulp!”

But then the Hare came and said: “Well done Wolf, you have implemented all seven features. But now I found out that there will never be all piglets in one home. You have to change your implementation!”. “No problem”, the wolf thought and quickly changed the database layer to fit the new needs. But lo! Now the test was broken and it was very hard to fix. The test tested all seven features at one stroke but now it tested features that were not correct anymore! Oh dear, what should the Wolf do now?

When the clever Fox heard of the Hare's misery he came and said: “Wolf, why do you create a big test image? You can create exactly the data you need for each test! And write many small tests. One for each feature!” What a wonderful idea that was. The Wolf added just the case that there is one piglet in the wooden house and tested exactly this in a dedicated test. Now the tests even served as a documentation of the features the Wolf had implemented. When the Wolf showed this to the Hare, he was very satisfied and thanked the Wolf many times. As Customers always do when they see that a software developer did a good job.

The Bear and the Grasshopper

There once was a Bear who had written a very big and very cozy backend for himself. “This backend is a very good one for a big Bear like me. It will suit me very well, and now I shall sleep for the winter!”, the Bear said to himself. He gave a big yawn and fell asleep.

But lo! A little Grasshopper jumped into the backend and hopped onto the Bears nose. This startled the Bear from his sleep and from the corner of his eyes he saw the Grasshopper jump away. “A bug in my backend! How can this be!”, the Bear growled with anger. He slammed his paw into the direction where he last saw the Grasshopper hop. “Let this be a lesson for you, little bug. And do not disturb my slumber again!”, the Bear growled and fell asleep once more.

Some time passed, but then the little Grasshopper came back. He was just hiding behind another feature! He jumped into databases table and onto the belly of the Bear. This woke the Bear from his sleep again and made him more furious than the last time. He hit his paw against all the tables and even added debug logging to the controllers. But he could not catch the little bug.

Then a Hedgehog who was disturbed by the noise came to the backend, “Bear, why do you make such a noise? Shouldn’t you be fast asleep?”. “There is a bug in my backend and I cannot catch it. When I look to the left it jumps to the right. And when I look here it jumps there.”, the Bear answered. The Hedgehog thought a moment for himself and finally said: “Bear you should write tests. Test everywhere you could see the bug and when you have tested all places he will be gone”. The Bear considered this and said, “Bears do not write tests and I do not see why this should help me. But I will do as you ask, for I am weary now and cannot sleep with a bug in my backend.“ And lo! After the Bear has written all his tests the Grasshopper had no place to hide anymore and was never seen again.

I hope you had as much fun reading these stories as me writing them. This post was sponsored by itemis AG. That's the place were I work and drink.