Showing posts from 2019

100% code coverage is false safety

It is really easy to lie to yourself when doing Test Driven Development that your code is good, safe, predictable and well understood, just because you have that magic 100% code coverage number.
If you test just the happy case it is easy to get to 100% code coverage, while still leaving code paths untested and unexpected behaviour unexplored.

Consider this simple function that takes in an object with 2 properties, an array of strings and a separating string to concatenate between them.

1: export const concatStrings = ({ strings, joiner }) => { 2: return strings.join(joiner); 3: };
Testing the Happy Path is really easy.
1: import { concatStrings } from "./stringConcat"; 2: describe(concatStrings, () => { 3: it("Should concatinate strings", () => { 4: const actual = concatStrings({ joiner: ", ", strings: ["one", "two"] }); 5: expect(actual).toBe("one, two"); 6: }); 7: })…

Unit testing Auth0 extension code

It is not obvious how to unit test Auth0 rule code. even if you're deploying it with the Auth0 Deploy CLI. You'll need to be using that to set up automated testing.

Auth0 expects rules to be uploaded in a very specific format, a single JavaScript function. Not exported in any way, just a single JavaScript function.  This makes it hard to test when running in Jest test runner environment.

The solution we used to overcome this was to wrap our function in a Self-Executing Anonymous Function. This function checks to see if module exists in the global object and exports in the case that it calls module.export if it doesn't exist it returns the function.

This allows us to write unit tests to confirm that our code works as expected, requires minimal extra code to maintain and the Auth0 Rule execution environment is able to execute our function.

N.B. if you are using the Auth0 configuration you'll need to provide a global object in your test code to test the use of these valu…

Middle Stack Developer

"Hi I'm Klee." "What do I do? Well... I'm trying to coin to term Middle Stack Developer." was the way I introduced myself across my time at Web Directions Code this past week. I like the idea of calling myself a Middle Stack Developer because I don't like the term Full Stack Developer. I don't believe that one person is able to fill out all the roles of a software delivery team. No, not even with so many companies providing SASS solutions that effectively provide specialists as a service.  What's a Middle Stack Developer? A general purpose developer, a willing generalist, someone who is happy to work across the the scope of software deployment and delivery while acknowledging that there will be places where they need to differ to a specialist.That is to say I can work in the browser but need someone to help me make things accessible and beautiful. I'm comfortable with Cloudformation but you'll need someone else to make your AWS instance …

JWT - Explain it to me like I'm 5

The following is a rough transcript of the talk I gave recently at the Newcastle JS meetup.  With the title JWT for 5 year olds.
This was one of the most fun talks I've put together and one that I hope everyone enjoyed.

Lets start with a story.

This is Millie. Millie has been baking cookies.

Millie has baked too many cookies and decides to take them to class. So she puts them in a box.
She takes the box to the teacher and says "Miss! Miss! Miss! I baked some cookies, can I hand them out to the class?"

The teacher looks at the cookies and says, "No! No you may not. If you want to hand out these cookies you need a note from you parent"

Millie runs out to the car and gets her father to write a note.

Millie takes the cookies and the note back to the teacher and asks "Miss! Miss! Miss! Here's my note, can I hand cookies out to the class?"

The teacher looks at the note and the cookies and says, "Yes! yes you can. This note says you can hand out coo…

AWS SAM/Api Gateway is swallowing my errors!?

AWS SAM is a great tool that has made my life so much easier when building Lambda functions that are accessible through API Gateway.

The one thing that has caught me out a couple of times is I don't get errors returned through API gateway when using the Node JS starter from $ sam init. 

As I'm testing I find a bug, as hard as I try I just cant manage to work out that "Just don't write bugs" coding strategy.  When I hit the bug I'm expecting to see the error as the response in Postman because of this block:

} catch (err) { console.log(err); return err; }
What I get though is a 504 response with no body.

While this is part of the starter if you want to return the value through API gateway when an unexpected error occurs you need to have the error wrapped in the same format as the body in the starter.  Like this:

} catch (err) { console.log(err); return { statusCode: 500, body: JSON.stringify({ err: err }) }; }

2018 review & 2019 goals

At the very end of 2017 I put together a quick blog post listed down some goals for things that I would like to achieve in 2018.  Now that we've ticked into 2019 I want to review what I put down and list out some new goals for 2019.
2018 in review Looking at the goals I set I did pretty well over all. Reviewing:  Speak More I managed, I gave several talks around Newcastle, got selected to speak at DDD Sydney for the 2nd year running and got selected to speak at NDC Sydney.  Submit More I managed to Submit to more than 5 conferences and was selected for 2 different talks.  Keep Coding & Keep Working I did both of these things. I'm still happily employed at nib and am still in a role that has me focused on code and systems development. I did fall down when it comes to Blog More. I only published 6 blogs last year, where ideally I would have liked to have published 12.

Overall 2018 went well I achieved a lot of the goals I set out to. Towards the end of the year after conference…