DEV Community: briwa

When you try your best (at what you're already good at) but you don't succeed...

briwa — Sun, 21 Jul 2019 15:10:28 +0000

Some of the people around me know that I like basketball so much. I did watch "Slam Dunk" growing up (one of my all-time favorite animes), but I wasn't really that much into the sport, was a couch potato and not even an athletic person. I only started learning and practicing when I was in university. Even that was only the basic: shooting. I remember one thing that my senior said to me; if you can shoot the ball well, you can consider yourself good enough. This statement somehow stuck in my brain for years to come.

And it's true. I did at some point get pretty good at shooting. Played with my fellow classmates and they started to respect myself when I got the ball, defending me closely. That was essentially my reward, what kept me going. Whenever we did practice, I wasn't interested in anything else but shooting. Whenever I practiced on my own, I also only practiced shooting most of the time. I mean, that's what I'm good at, might as well focus on that instead.

Then come a bigger scene. I played with different people, full court 5 on 5. It was a whole different level of basketball, I was flabbergasted. I could barely get ahold of the ball, and even if I managed to shoot them, I could rarely make the shot, it was intense. Everyone started telling me this and that. I didn't have a good stamina, I should've passed more, I should've played better defense. I said to myself, they're not getting it; you guys should've given me the ball, cleared the defense and I could've scored better! I know what I'm doing!

And I was somewhat right. During practice, I could make my shots. I repeated the same shots on the same spots that I missed during the actual game, and I could make them. However, during the game, my shots weren't falling again. My teammates started to pass to someone else instead of me. I was befuddled at first, but then I thought, the hell with it, I'm not gonna play anymore. I mean, it was frustrating. I've practiced, I've shown great signs of improvements, I did my best, but it wasn't enough. There's always something else that everyone else demanded. My shooting works, why can't they appreciate what I can do and my efforts instead?

At that point, I've been learning basketball for at least 5 years, although it wasn't that intense. Probably once or twice every week, and it was an on and off thing. And then it hit me. 5 years... and I only know how to shoot? Even so, I was still struggling in making my shots at games? What have I been doing in these past 5 years?

So I started to watch basketball games instead. The NBA. Looking at how organized they played, multiple sets of offense and defense, how are they running up and down the court. That's where I realized what went wrong in those 5 years: There is a whole lot more to it than shooting in basketball (duh). Sure, what my senior said at the beginning was right, but I should have never stopped at shooting.

More importantly, I also realized that indeed I was not good enough. The skill gap between talented basketball player and me has to be acknowledged. It was wrong to keep repeating to myself that "my shooting works and I did my best", while ignoring the rest of my problems. I needed to get out of that shell and start listening and improving.

It wasn't exactly a fun experience. I remember practicing dribbles and layups for months, started to work on my stamina. Practiced harder and more frequent than I used to. I was basically doing what beginners do despite of starting way earlier than them. However, my game felt more complete, and I could really make it work with my teammates afterwards, started making my shots somehow.

You'd probably wonder, "How does any of these have anything to do with programming? This is dev.to and there's no #watercooler tag in this article!" My bad, I might have gotten carried away (I like basketball that much, to be honest). However, maybe some of you can already relate to it, when comparing with your work experience: being in the field for years, have been sort of good at insert-programming-language-here, but somehow your supervisors or your coworkers (or even yourself?) are telling you that you're not good enough?

I think, to overcome the fact that you're not good enough and you still have so many things to catch up, it is important to first acknowledge the fact that you're not good enough. I know this may seem like you're stirring up the Impostor Syndrome pot that is already boiling hot, but I don't think you can improve without acknowledging what needs to be improved. Patching it by saying "I did my best, why can't you see my effort" or "I'm already good at X Y Z" did not help, as you might have learned from my 5 years of practicing basketball; it is still not addressing the actual problems, which are the areas you're lacking. Then, make actionable items from those and start to improve.

I have to say that accepting the fact that you're not good enough is truly essential in terms of improving yourself, in my case at least. It teaches yourself to lower down your ego, and avoiding yourself to be pigeonholed into your own opinion. It also allows yourself to be able to properly listen to critics; if you found yourself getting easily offended or defensive when getting a feedback, maybe it's because you've been dodging the fact that you are getting a feedback. Acknowledge them first, maybe take a breather, and start to listen, and then see if the feedback makes sense.

Furthermore, it is okay to make yourself look like beginners once in a while, especially if you are, and you have acknowledged or accepted the fact that you are. If it happens that folks have been telling you that you're not good enough at Git despite of having been working in IT for years, it is fine to get that "How to Git for Dummies" book and get to the bottom of it. In my opinion, it doesn't make you less of a person, it's just that you happen not to know that thing in particular. That is super normal. And this is an experience that would make you a much humbler person, which is great in general.

Anyway, there's already a lot of articles about Impostor Syndrome and how you can get out of that feeling of not good enough or not deserving your current situation. I didn't mean to sound like a broken record, but currently this is an offseason in NBA and there isn't that much basketball topic to talk about, so I thought why not 😂. Also, it seems to me that it's still not the most obvious thing to point out when it comes to this topic, at least for me, so just to get the word out.

Still, thank you for reading my article, I hope this helps someone in some ways!

Cover image by Tamarcus Brown on Unsplash.

The League of (Five) Extraordinary Javascript Resources

briwa — Sun, 14 Jul 2019 11:51:38 +0000

Just ignore the title. I really can't find one title that represents all the links I'm going to share this article, but anyway. I've read articles, videos, tutorials about Javascript, but those who really stood up are only a few. And usually it's those that are visually appealing, attention-grabbing and entertaining.

Of course, you take those away, and it's still something worth sharing. But I really admire the people who took an extra mile just to visualize their ideas, to convey their messages in a way that they and their audience love. It is really something to admire, and it's a skill that I'm also learning to do.

Anyway, just a little disclaimer that I am not in a way endorsed or sponsoring any of those links, nor I get any benefit from sharing it. Most of them are open sources anyway. I'm just sharing it so that maybe it can inspire you too. Here it goes.

1. Untrusted (https://alexnisnevich.github.io/untrusted/)

I can't remember where I found this, but the first time I saw it, it reminded me of the DOS games I've played when I was young. Back then, graphical interfaces are limited, but somehow I didn't even remember it was that bad, mainly because of the storyline and how cool it was at that time.

Just like this game, it wasn't the limited interface that stood up in my memory, it was the fact that it combines the two worlds that I love: adventures and learning Javascript. The game started out simple just like any other adventure, solving simple problem in Javascript to advance to the next level. You will have to use all the things you know about Javascript (with certain rules), and at times you are required to think out of the box. I can't say more on this otherwise it would spoil the game!

It is really fun. Mad props to the creator. You should check it out too.

P.S.: Speaking of simple yet addictive game, I'd like to give another shout out to https://github.com/doublespeakgames/adarkroom, a text-based game that could turn minutes to hours real quick.

2. https://regexr.com/ (https://github.com/gskinner/regexr)

If you're like me, who are still struggling to make a mind map of what symbol does what in RegEx, and you're in a constant need of visual cues, regexr is for you. It breaks down every single tokens in a RegEx syntax and explain what it does, while asserting the syntax live on to the example string that you can customize. Not only that, there are references on the sidebar on the common RegEx tokens that you would use, also with examples.

This website really takes the cake because of the way it is presented. It has everything from a sandbox to community-driven examples. And it's open source! If you're thinking of contributing or curious about the code, you can always check out the Github repo. Very recommended. Also, if you have other websites about RegEx, let me know in the comments, since I really need to step up my RegEx game.

Note that this is mainly applied to Javascript and PHP RegEx syntaxes.

3. https://dwitter.net/ (https://github.com/lionleaf/dwitter)

I saw a few posts from the #challenge tag recently, and I immediately thought of Dwitter. It's taking code challenge and code golfing to a whole new level! You are given a canvas that has some predefined code to start with, just enough to get it up and running. Then, you can write your own code in just 140 characters and go wild with your imaginations! People are mostly creating animations, but I think I've seen someone creating a game before.

It's not just showcasing what you can create, it is also similar to dev.to where you could browse, "like", share and comment other's creations. You could also remix them, similar to how you can do so in Glitch. It also has a wholesome community. Check it out.

4. https://observablehq.com/ (https://github.com/observablehq)

One of the articles that got me into writing is this article about Fisher-Yates shuffle. A concept that could've been complicated for me was presented in such a way that it's almost as if I was reading a story. The pacing, the visualization, the way it was written. From that moment, I kept thinking about this article and my dream is to write one like these.

Later on, I found out that the writer is actually Mike Bostock, the person behind d3.js, a Javascript visualization library. I've been using the library for a different project, and had since then become a fan. A little bit of digging and then I also found out that he co-founded another project called ObservableHQ.

I've seen Jupyter Notebook before and ObservableHQ reminds me of that. A place where you can write articles that "speaks", and also a place to share. It is filled with the articles similar to what I mentioned earlier. The key is actually both visualization and interactivity; it really redefines how you present an idea. I really liked it, and you should check it out if you haven't.

5. Jake Archibald - In the Loop (https://www.youtube.com/watch?v=cCOL7MC4Pl0)

This last one is a bit different; a video instead (because I'm running out of websites, and also because it's super cool). I was lucky enough to have the privilege to watch this live on one of the conferences. Jake Archibald was presenting the concept of event loop, something that I often get confused with and made me realized that abusing setTimeout was never a good idea to begin with. He explained in such a way that I believe someone who just got into frontend development can understand.

To add to that, he is one entertaining speaker on the stage; he knows how to get the audience going, sending out jokes left and right. I can learn a lot from him both about event loop itself and public speaking. Not sure if the person is on dev.to, but shout out to him.

P.S.: My second favorite video is from David Neal (@reverentgeek ): https://www.youtube.com/watch?v=-I8QHkZreyo. His drawings in the presentation is on point. You should check this one out too.

What's your favorite extraordinary Javascript resources? Or maybe you've checked some of these ones out already? Let me know in the comments below. Thank you for reading!

Cover image by JOSHUA COLEMAN on Unsplash.

A Series of My Unfortunate Mistakes (When Writing Tests)

briwa — Sat, 06 Jul 2019 19:09:59 +0000

Once upon a time, when I started writing tests long time ago (actually, not that long, maybe a few years ago), I was a naive young man. I hate bugs so I write tests, and I wrote them according to my limited knowledge at that time.

Being naive and not exactly up to date with the references have a price. From each and every rejected PR review or regression bug, I've learned so much from my mistakes, and it made me realize that I had so much to improve. It is indeed unfortunate for me, having to learn through trials and errors, but it doesn't have to be unfortunate for you!

Say, fellow developers, should you feel that your test is not good enough, or your PRs have been rejected by the QA team too many times due to the lack of test quality, maybe you'll find this article useful. I am going to share with you the top five mistakes that I've made when writing tests, and why you should avoid them.

Before that, a disclaimer: the example code below is written in Javascript using Jest as the test framework. My focus is just specifically on Javascript so I can't comment much on the others, not sure if it can be applied. Also, these are just simplified examples, it does not represent actual use cases. Just to get the point across.

Alright. Right on to the example. Supposedly I was writing this class:

class Account {
  constructor (initialBalance = 0) {
    this.balance = initialBalance
  }

  deposit (money) {
    this.balance += money
  }

  withdraw (money) {
    this.balance -= money
  }
}

Right now, the class is just simple. It has a way to deposit and withdraw an amount that would alter the balance. And my journey of writing the tests begins here.

1. Not keeping the test simple

First thing I wanted to test is the .deposit method. In my mind, the test has to be super specific, everyone else that reads the test wouldn't even need to see the actual code.

const account = new Account()

describe('Account class', () => {
  describe('.deposit', () => {
    test('Should increment the account balance by the amount', () => {
      const increment = 200
      const originalBalance = account.balance
      account.deposit(increment)
      expect(account.balance).toBe(originalBalance + increment)
    })
  })
})

The test looks good, right? It has the original balance, it has the amount to increment, and it asserts the original balance plus the increment. In fact, if I wanted to change the amount of the increment, I would only need to change the increment variable, and the test would still pass. That's it. Super easy.

Then came a new requirement. Every amount that is being deposited will be added 2% on top of the amount, as the incentive (don't ask me why, it's the PM...).

  deposit (money) {
    this.balance += (money * 1.02)
  }

Hmm, yup, okay. So the test would be....

    test('Should increment the account balance by the amount plus 2% incentive', () => {
      const increment = 200
      const originalBalance = account.balance
      // PLEASE SEE TEH CODE FOR THE CLASS FOR REFERENCE
      const incrementPlusIncentive = increment * 1.02
      account.deposit(increment)
      expect(account.balance).toBe(originalBalance + incrementPlusIncentive)
    })

Oh gee, what is this monstrosity? My idea was to make it clear, but I ended up making it more complicated. Furthermore, I am duplicating the logic in the code to the test. That's not right.

In practice, test code should only be explicitly stating what you're testing (input -> output). No logic code should be there; it belongs to the code you're testing. Which is why, an improved version would be:

    test('Should increment the account balance by the amount plus 2% incentive', () => {
      account.deposit(100)
      expect(account.balance).toBe(102)
    })

There you go. Keep it simple. I am depositing 100, my balance is now 102. Is it according to the requirement? Absolutely! And that's what matters the most.

2. Not maintaining a clean state on each tests

My next quest is to write the rest of the test. .withdraw it is.

const account = new Account()

describe('Account class', () => {
  describe('.deposit', () => {
    test('Should increment the account balance by the amount plus 2% incentive', () => {
      account.deposit(100)
      expect(account.balance).toBe(102)
    })
  })

  describe('.withdraw', () => {
    test('Should decrement the account balance by the amount', () => {
      account.withdraw(100)
      expect(account.balance).toBe(2)
    })
  })
})

Hmm, yup, looks good. However, some of you might already notice it: there's a code smell. Why is that the tests are sharing one account instance? Wouldn't that make the order of the test matter, when it shouldn't? If we swap the order, it would definitely break. That is not right.

describe('Account class', () => {
  describe('.deposit', () => {
    test('Should increment the account balance by the amount plus 2% incentive', () => {
      const account = new Account()
      account.deposit(100)
      expect(account.balance).toBe(102)
    })
  })

  describe('.withdraw', () => {
    test('Should decrement the account balance by the amount', () => {
      const account = new Account()
      account.withdraw(100)
      expect(account.balance).toBe(-100)
    })
  })
})

By creating the account instance every test, it is ensured that the test begins with a clean slate. It can be modified as much as it wants, because it is contained in the scope of the particular test, and it is independent to each other. That way, the order of the test doesn't matter. Say, if we're using a test runner that runs in parallel and randomizes the order of the tests, it will still be passing just fine.

And by the way, there's beforeEach/afterEach (or setup/teardown) helper that we can also use to initialize and clean up every test suites, but it's rather complicated to explain here, so maybe for another article.

3. Not asserting the state properly

Next up, the project goes big, apparently there was some housekeeping going on, and now all code has to be commented, put it a proper file and whatnot.

/**
 * Account class.
 */
class Account {
  /**
   * Constructor function.
   * 
   * This sets the initial balance when initializing the instance.
   * 
   * @param {Number} initialBalance 
   */
  constructor (initialBalance = 0) {
    this.balance = initialBalance
  }

  /**
   * Increment the balance by the given sum of the amount.
   * An incentive of 2% of the amount will be added
   * for each deposited amount.
   * 
   * @param {Number} money 
   */
  public deposit (money) {
    this.balance = (money * 1.02)
  }

  /**
   * Decrement the balance by the given amount.
   * 
   * @param {Number} money 
   */
  public withdraw (money) {
    this.balance -= money
  }
}

Alright, done. I didn't notice anything wrong (or did I? 😏 You'll find out soon enough). I checked out the Jest console and it says...

Account class
  .deposit
    ✓ Should increment the account balance by the amount plus 2% incentive (5ms)
  .withdraw
    ✓ Should decrement the account balance by the amount

Still passing, obviously. Duh. Committed, PR reviewed, CI build passed, merged and deployed. That was a fun Monday.

...but not really. Users are screaming that their balance is reset to the amount they're depositing. What is happening? How did that happen when the tests are passing?

I looked at my code, looked at the test, nothing seems wrong. Is it the initial balance? Because I didn't have a test for that (oops). So I go ahead and update the test as such:

  describe('.deposit', () => {
    test('Should increment the account balance by the amount plus 2% incentive', () => {
      const account = new Account(100)

      account.deposit(100)
      expect(account.balance).toBe(202)
    })
  })

Lo and behold, not just the users, Jest is also screaming now (?)

  ● Account class › .deposit › Should increment the account balance 
    by the amount plus 2% incentive

    expect(received).toBe(expected) // Object.is equality

    Expected: 202
    Received: 102

      11 |
      12 |       account.deposit(100)
    > 13 |       expect(account.balance).toBe(202)
         |                               ^
      14 |     })
      15 |   })
      16 |

      at Object.toBe (__tests__/index.test.js:13:31)

The bug appeared! This is exactly what users were reporting. Now the test actually failed. After looking at the code (and you can compare with the code from the beginning of this section), I noticed one tiny mistake:

  deposit (money) {
    // The plus was missing 🤮
    this.balance += (money * 1.02)
  }

Yup, there you go. A supposedly harmless refactoring went on to cause a bug, probably the plus was removed by accident. And the test couldn't catch it. I should have written it the proper way in the first place.

If the code is about value accumulation (not value assignment), it has to be tested in such a way that the previous value is accumulated with the value given. The previous assertion was sort of incomplete because it is just testing the value assignment.

  // 🤔 
  describe('.deposit ❌', () => {
    test('Should increment the account balance by the amount plus 2% incentive', () => {
      const account = new Account() //... What's the previous value?

      account.deposit(100) // Amount is 100
      expect(account.balance).toBe(102) // Final value is 102...?
    })
  })

  // 😎
  describe('.deposit ✅', () => {
    test('Should increment the account balance by the amount plus 2% incentive', () => {
      const account = new Account(100) // Previous value is 100

      account.deposit(100) // Amount is 100
      expect(account.balance).toBe(202) // Final value is 202
    })
  })

To tie the knot, the constructor function has to be tested as well. This ensures the instantiation part is being covered properly (maybe if the constructor function has some logic, it can be asserted as well).

  describe('constructor', () => {
    test('Should set the initial balance when instantiated', () => {
      const account = new Account(100)
      expect(account.balance).toBe(100)
    })
  })

Maybe this section is rather specific, but the point is, always test the whole flow of the state (before/after, I/O), not just partially. At least that's what I've learned.

4. Not structuring the tests properly

I have received words from the QA team that I haven't been catching edge cases properly. Values in .deposit can be anything, and the error isn't intuitive enough.

Also, new requirement came: the account should be able to deposit more than one single amount, then make a sum out of it.

Fine. The .deposit code now looks like this:

  /**
   * Increment the balance by the given sum of the amount.
   * An incentive of 2% of the amount will be added
   * for each deposited amount.
   * Only number is allowed, otherwise an error is thrown.
   * Also, the number should be greater than 0.
   * 
   * @param {Number[]} ...args 
   */
  deposit (...args) {
    if (args.length === 0) {
      throw new Error('Please provide at least one argument.')
    }

    const amount = args.reduce((total, value) => {
      const number = parseInt(value, 10)
      if (isNaN(number)) {
        throw new Error('Please specify a number as the argument.')
      }

      if (number <= 0) {
        throw new Error('Please specify a number greater than 0.')
      }

      return total + (number * 1.02)
    })

    this.balance += amount
  }

...but the test isn't looking as good:

  describe('.deposit', () => {
    test('Should throw an error when no amount is given', () => {
      const account = new Account()
      expect(() => account.deposit()).toThrowError('Please provide at least one argument.')
    })

    test('Should throw an error when amount given is not a number', () => {
      const account = new Account()
      expect(() => account.deposit('a', 'b', 'c')).toThrowError('Please specify a number as the argument.')
    })

    test('Should increment the account balance by the sum of the amount plus 2% incentive, only when the amount is greater than 0 otherwise it should throw', () => {
      const account = new Account(100)

      account.deposit(100, 200)
      expect(account.balance).toBe(406)

      // ...but not less than 0!
      expect(() => account.deposit(0, 400, -200)).toThrowError('Please specify a number greater than 0.')
    })
  })

Wow, the last part of the test was quite a mouthful. Whatever 🙄. Job's done, and tests are passing.

  .deposit
    ✓ Should throw an error when no amount is given (4ms)
    ✓ Should throw an error when amount given is not a number (1ms)
    ✓ Should increment the account balance by the sum of the amount plus 2% incentive, only when the amount is greater than 0 otherwise it should throw (5ms)

However, QA team says that the test is a mess! It's hard to understand, and the last part of the test is doing too much. In general, it is better to split the tests into multiple contexts, so that there are layers of conditions to assert, and one test should simply do one thing based on the context.

An improved version would be:

  describe('.deposit', () => {
    describe('When no argument is provided', () => {
      test('Should throw an error', () => {
        const account = new Account()
        expect(() => account.deposit()).toThrowError('Please provide at least one argument.')
      })
    })

    describe('When the arguments are provided', () => {
      describe('And the arguments are invalid', () => {
        test('Should throw an error', () => {
          const account = new Account()
          expect(() => account.deposit('a', 'b', 'c')).toThrowError('Please specify a number as the argument.')
        })
      })

      describe('And the arguments are valid', () => {
        describe('And the arguments are less than zero', () => {
          test('Should throw an error', () => {
            const account = new Account()
            expect(() => account.deposit(0, 400, -200)).toThrowError('Please specify a number greater than 0.')
          })
        })

        describe('And the arguments are all more than zero', () => {
          test('Should increment the account balance by the sum of the amount plus 2% incentive', () => {
            const account = new Account(100)
            expect(account.balance).toBe(100)

            account.deposit(100, 200)
            expect(account.balance).toBe(406)
          })
        })
      })
    })
  })

The multiple layers of context is useful when the code grows even more complex. It's easier to add more contexts when it is already split as layers like that. For example, if I were to add a new validation (maybe there should be a maximum amount to deposit) and I was supposed to add a test for that, I know where to put them in the structure, nice and tidy.

The order of the layers are mostly my preference. I love seeing edge cases at the top and the actual logic at the bottom, kinda like how guards (or the actual validation) is written in the code.

And here's how it looks like on the Jest output:

  .deposit
    When no argument is provided
      ✓ Should throw an error (7ms)
    When the arguments are provided
      And the arguments are invalid
        ✓ Should throw an error (2ms)
      And the arguments are valid
        And the arguments are less than zero
          ✓ Should throw an error (2ms)
        And the arguments are all more than zero
          ✓ Should increment the account balance by the sum of the amount plus 2% incentive (2ms)

Now I kinda have to agree with the QA team.

5. Not trusting the libraries you're using

The stakeholders say that there are hackers withdrawing money that weren't theirs from the account somehow. Due to that issue, the .withdraw function won't simply be deducting the balance; it has to go through some validation script magic so that it knows if it's being tampered by the hacker (I'm not sure how, this is just an example code).

  /**
   * Decrement the balance by the given amount.
   * It is now using a validator from backend
   * which I don't know how it works.
   * 
   * @param {Number} money 
   */
  withdraw (money) {
    const currentBalance = this.validateAndWithdraw(money)
    this.balance = currentBalance
  }

  validateAndWithdraw (money) {
    // This validator might throw an error if the transaction is invalid!!!
    return superDuperValidatorFromBackend(money)
  }

Due to the expensive cost of actually running it in Jest, I would rather mock the function that does the validation. As long as it won't throw me an error and give me the actual balance, it should be good to go.

  describe('.withdraw', () => {
    describe('Given a valid withdrawal', () => {
      test('Should set the balance after withdrawal', () => {
        const account = new Account(300)

        // Override this function to avoid having to actually request from backend.
        // It should just return the balance without any error thrown.
        jest.spyOn(account, 'validateAndWithdraw').mockImplementationOnce(() => 200)

        expect(() => account.withdraw(100)).not.toThrow()
        expect(account.validateAndWithdraw).toHaveBeenCalledWith(100)
        expect(account.balance).toBe(200)
      })
    })
  })

I added not.toThrow() there so that I know when I call the .withdraw function, there is no error thrown, because I mocked it. Right? Right?

Wrong. -- QA team

Eventually, I learned that the tests that I write should only cover the business logic of my code. Testing whether it is thrown or not shouldn't be my test's responsibility, because the function implementation has been mocked by Jest, as I specified it in the test, so that the error won't be thrown. There is no need to assert if it should throw, because it will never throw!

...but how can you be so sure, though? -- My awkward testing skill

One can always check Jest's repository, the source code and how they're testing them, and if it's passing. There might even be the exact code, who knows. The point is, I have to trust the libraries I'm using, and it is their test responsibility to make sure that their code works, not mine. My test should focus on the actual logic on my code instead.

  describe('.withdraw', () => {
    describe('Given a valid withdrawal', () => {
      test('Should set the balance after withdrawal', () => {
        const account = new Account(300)

        // Override this function to avoid having to actually request from backend.
        // It should just return the balance without any error thrown.
        jest.spyOn(account, 'validateAndWithdraw').mockImplementationOnce(() => 200)

        account.withdraw(100)
        expect(account.validateAndWithdraw).toHaveBeenCalledWith(100)
        expect(account.balance).toBe(200)
      })
    })
  })

That's it. Only business logic allowed.

And that concludes the end of my journey, for now. Who knows what the future (mistakes) holds...

Also, some of these mistakes might be obvious. But these points still stand. I just thought that I'd share. If you have any feedback on these suggestions, or maybe it wasn't such a mistake after all, let's discuss in the comment section below.

I hope you enjoy reading this article, and thank you!

Cover image by Jamie Street on Unsplash.

(Fantastic) XY Problems and How to Avoid Them

briwa — Sat, 29 Jun 2019 18:13:46 +0000

Have you ever come across a question that makes you wonder what was the purpose behind it? Maybe something like this:

Do you know the regex to achieve this? https://dev.to/new => /new

(To be honest, I don't know the answer of this question off the top of my head, anyone?)

Due to ~~my weak regex game~~ my curiosity, I would instead ask, "What's the context?". Without a proper context, it would be hard to define the solution. Does the regex have to include query parameters? How about URL hashes? What's the level of the depth of the URL? Is it the current page URL or simply just any URL? And so on.

If the context is about the current page URL, URL.pathname can be used instead:

// When the URL is "https://dev.to/new"
window.location.pathname // Returns "/new"

If this was indeed the context, we all learned that the regex was never needed in the first place. Who knows if the context was never provided, a wrong solution would have been presented instead. And time might have been already wasted.

From what I understand, the aforementioned example a simplified case of an XY problem. In summary, it is when a problem is trying to be solved with a fixed solution at hand, nullifying the rest of the possible (maybe better) solutions, while ignoring the context of the problem in the first place. I used to think that this was a classic problem that only happened in the past, where in fact this is pretty much common nowadays, even outside of the programming use cases.

Take some more (extreme, hypothetical, maybe fantastic?) examples:

An office will be providing winter coats for their employees due to the freezing air coming from the air conditioners; shouldn't they be asking why the air conditioners have to be that cold in the first place?
All pull requests without any tests will be closed automatically by a bot due to the alarming decrease of the test coverage percentage; shouldn't the devs be asked as to why they didn't write the test in the first place? Or isn't there a better way to do this, maybe block the PR from merging instead?
Developers will be required to write their initials as a code comment right above the code they modify, due to bugs happening in production and no one to attribute the bugs to; I mean, sure, but don't we have git blame for that? Or maybe services to track errors in deployments and point out the breaking version? Shouldn't the QA/code review process be improved instead?

I hope none of these are relatable. If we look at it this way, the flaws of these solutions are so obvious that it is impossible to miss them. And the fact that no other solutions are presented should throw you off from the very beginning. But when it happens inside a meeting room, filled with people that have the same level of context (or the lack thereof), it might not be that obvious, and a not-so-well-thought-out solution might come out as the result.

If you (or anyone) are about to solve a problem and you would like to avoid XY problem, regardless of whether it's a programming problem or any problem in general, I would suggest to try these steps before solving them:

Take a step back and observe the problem once more.
Regardless of whether you already have a solution or not, get as much context from the problem as you can. Consider all cases that are required to solve the problem. One way to see if you've done enough due diligence for the problem is that if anyone asks any questions about the problem, you have the strong answer to it already. If not, note that down and continue observing the problem.
If you have no solutions at the moment, present these contexts right away. At this point, they should have all that is needed to formulate a solution. Maybe you could already try StackOverflow or StackExchange. If this is about decision making and you have some ideas on the solution already...
Think of not just one, but multiple solutions.
It's okay to have a favorite solution, maybe it's something that you are already an expert of, or something that you prefer in terms of the implementation. However, it is important to be fair to the rest of the people that are involved in the process (also, to the rest of the solutions). Come up with more than one solution so that there is something to compare with. If you can't think of anything, that is fine, as long as you're being up front about it. With enough context, you could initiate a brainstorming session instead, to explore the rest of the solutions.
Weigh in all the pros/cons.
Ranking all the solutions by pros and cons would make the decision making process a whole lot more efficient. This would put the good ones in the spotlight and eliminate the bad ones, instead of having to randomly check each solutions one by one. And also, pros and cons have to be validated on all aspects: resources, effects on performance, maintainability, long-term support, I think you get the idea.
Sometimes, this process could tell if the solution candidates are truly legit, instead of one favorite solution and an intentional mix of bad ones. If what happens is the latter, this is a sign of a bad brainstorming session and repeat step 2.
Be open ended as much as possible.
Last but not least, it is important to remember that you are not telling people to agree with you and solve the problem using your favorite solution. The whole process is to find a solution to the problem. It is never about about who is right or whose solution is the best. So, keeping it open ended is essential; the only aspect that is fixed is the problem anyway, not the solutions.

I know that this topic may have been brought up quite often, and I was actually inspired by this jolly good article (you should check it out if you haven't), and this concept is nothing new. I'm jotting it down as a reminder to myself, and also to share with others that aren't too familiar with the topic.

If you've seen XY problems in the wild and would like to share yours, do let me know. And if there's any feedback about the article, let me know as well. Thanks for reading my article.

Cover image by Pierrick VAN-TROOST on Unsplash.

How are technical decisions being made in your company?

briwa — Sun, 23 Jun 2019 14:21:17 +0000

There are technical decisions that sometimes dictate how the company is going to move forward a few years into the future, of course for the better. We've probably heard a few big companies did that (examples: 1, 2, 3). I think you all get the idea.

When it comes to these kind of decisions, how is it being made in your company? A few questions:

Who came up with the decision? CTO/tech lead/devs?
Who did the research on the decision? And how long did the research take?
What triggered the decision? Was it set on a technical roadmap, or simply the product you're developing demanded it at that time?
How was it being executed? Was it done gradually, or in one go (production stopped, all devs refactored the code until it is finished)?
How did the devs perceive the decision? Did they follow because they agreed, or was it something that the devs had to follow regardless?

These questions might be a lot to answer, but I'm trying to understand the processes in other companies, so that maybe I can learn a thing or two and apply it in the company I currently work in.

Thank you in advance, for your insights. Much appreciated.

Me: "I tested and it works, why do I have to write tests?"

briwa — Sun, 23 Jun 2019 03:47:11 +0000

I started out programming in PHP and Javascript when I was studying in university. Back then, I knew nothing about any kinds of software testing. The only way to make sure that the code works is to test them manually in the browser. I would imagine that bigger companies with more complex software would have a dozen of people lining up in front of their software interface, testing them manually.

I remember there was even a spreadsheet, filled with rows of use cases, with checkboxes to tick before launch. Even with that, the bugs still appeared. When I shipped the code, I did manual testing on several cases that I was aware of, but there is no way I could test all the possible cases that the app would allow. It was one of the most counter-productive moments in my development career.

Then I discovered software testing. It was such a blessing. The way it covers use cases systematically, maintain the app stability, and how it is done automatically with Continuous Integration truly amazed me. No more spreadsheet with millions of rows, and I can ship code with more confidence.

In my opinion, the concept of testing is still hard to accept to some, even now. I can understand that this is mostly fear of change; trying to get people out of the comfort zone of "I coded it and it works" is not an easy task. I remember a few arguments against testing:

"I have confidence in my code, it won't break."
"I tested all the use cases, they're fine."
"You can review my code, point out the flaws, and if there's none it should be good to go."

All the arguments came from the "human" factor of the developer: their code confidence, their manual testing skills, their flawless code. And it is important; nothing to take away from that. Software testing, on the other hand, covers the cases when the "human" factor is failing. Nobody is perfect, mistakes are bound to happen and we learn from the experience. When you write the code, or even when people review the code, and some use cases/flaws are being overlooked, the test might be able to point that out.

And not just about maintaining stability and the quality of the code. Tests define the specification of the code. I was just being dense, but it just occurred to me as to why tests are called "specs" in the first place. When writing tests, it is made very clear from the start on what the code can and cannot do. Recently, I even started developing a habit of browsing the test folder of a library to find out what it does when I can't find them in their API/demo page, and it does really help.

Even with all the good stuff about testing being laid out, getting people on-boarded is definitely another problem. I can see how people are still treating tests as "something that would allow me to merge PRs". Some would probably still say "the feature works and I tested it, we can merge it first and I'll write the test later". Others would complain that "lots of tests failing because I changed one line of code".

In my opinion, they are missing the big picture. If you make changes on the code, of course you have to make all tests passing because you're making sure that your code is still within the specification of the code (the test). If you add a new code, you have to add tests because you're adding new specifications to the software. If you're shipping a code without a test, that would mean you're shipping code without a specification; nothing is set in stone about what works and what doesn't, including bugs.

There are reasons why most open source repositories are taking tests very seriously: because they care so much about their code stability. One single bug could put lots of people at stake, the devs and its users. PRs with failing builds or no tests wouldn't even be reviewed. I would say it shouldn't be that much different compared to our own (for-profit, maybe?) projects. It might be hard to convince clients/stakeholders that testing is important, but at least it shouldn't be made that hard for the devs.

This article might not apply to you. I am aware that there are many practices that integrate testing into their workflow (e.g. Agile), and a lot of companies have already been doing that. But, if it does apply to you, I hope this article provides another point of view of what testing is and why it is important, and maybe you can finally get rid of that giant checkbox-ridden spreadsheet.

As always, thanks for reading my article!

Cover image by Glenn Carstens-Peters on Unsplash.

From JSX to Vue: my favorite templating tips

briwa — Sat, 15 Jun 2019 16:02:01 +0000

Coming from using JSX, I am amazed by the built-in templating features that Vue has. Since I'm one of the late adopters, these might not be new to you, but I wish I had known these perks when I started migrating to Vue. So, hopefully this helps people who are in the midst of migrating, trying out Vue, or maybe thinking of using Vue?

Anyway, here are some of my favorites.

1. `v-if`, `v-else` and `v-else-if` for conditional rendering

In the component, there would always be some conditions for the templates to be rendered. I learned that v-if can toggle elements to be rendered while supplying the condition. An example would be:

<!-- Basket.vue -->
<section id="the-one-fruit-to-buy">
  <orange v-if="sourFruitSelected && isExpensive" />
  <grape v-if="sourFruitSelected && !isExpensive" />
  <apple v-if="!sourFruitSelected">
</section>

In this case, I only want to show one component at a time. If sourFruitSelected and isExpensive is true, orange would only be shown. Looking at the logic, this should look fine on browsers. But, if you look at the HTML, you would see something like this:

<!-- Inspecting the HTML -->
<section id="the-one-fruit-to-buy">
  <div id="orange-component"></div>
  <!----->
  <!----->
</section>

Two elements are rendered with  because the v-if statement is false. This is because every v-if is a single condition to the element it is targetting. Vue won't know that only one of the three elements is supposed to be shown if I'm using three v-ifs, which is three conditions to three different elements. Therefore, I should combine it with v-else-if and v-else:

<!-- Basket.vue -->
<section id="the-one-fruit-to-buy">
  <orange v-if="sourFruitSelected && isExpensive" />
  <grape v-else-if="sourFruitSelected && !isExpensive" />
  <apple v-else>
</section>

This means it is just one condition to toggle three elements. In the HTML, it would look like this:

<!-- Inspecting the HTML -->
<section id="the-one-fruit-to-buy">
  <div id="orange-component"></div>
</section>

But wait, there's more! While the conditional statement is valid, it can be hard to follow. How do we avoid sourFruitSelected and isExpensive logic repetitions? <template> tag can help you with that.

v-if is a directive, so it only works on a single element. If we put v-if to a <template> which is an empty wrapper of elements, we could improve the logic as follows:

<section class="the-one-fruit-to-buy">
  <template v-if="sourFruitSelected">
    <grape v-if="isExpensive">
    <orange v-else />
  <template>
  <apple v-else>
</section>

2. `<component>` tag to avoid repetitions on similar components

Supposedly I was building a chart component with Vue that looked like this:

<!-- Chart.vue -->
<chart
  :width="width"
  :height="height" />

Over time, I realized that I need more types of charts, built differently for each types, so the code now looks like this:

<!-- Chart.vue -->
<pie-chart
  v-if="type === 'pie'"
  :width="width"
  :height="height" />
<bar-chart
  v-else-if="type === 'bar'"
  :width="width"
  :height="height" />
<column-chart
  v-else-if="type === 'column'"
  :width="width"
  :height="height" />

You noticed that there is some kind of pattern, right? With <component> tag, I can improve the template as such:

<!-- Chart.vue -->
<component
  :is="`${type}-chart`" 
  :width="width"
  :height="height" />

This basically means it will render a component that has ${type}-chart as its name, defined under :is. Since all components share the same props (width and height), both will be passed down to each rendered components.

Do note that all the possible components have to be registered in the parent (or installed globally) in order for this to work.

3. `<slot>` tag for shared component reusability

Say I was implementing a modal component, and I would use it as such:

<!-- Parent.vue -->
<modal :text="'Lorem ipsum'" />

The actual component would just be:

<!-- Modal.vue -->
<div class="modal">
  {{ text }}
</div>

Then, I wanted to add actual HTML elements to the modal, like forms. Not just a simple text. How do I parse the string prop as HTML?

With <slot>, you can place any content from the parent down to the component's template. You shouldn't be using the prop anyway. So, the modal component template would be:

<!-- Modal.vue -->
<div class="modal">
  <slot />
</div>

And the parent component that uses the modal would just be:

<!-- Parent.vue -->
<modal>
  <form>
    <h3>Do you want to delete these files permanently?</h3>
    <button>Cancel</button>
    <button>Delete</button>
  </form>
</modal>

I think slots is one of the most interesting feature in Vue, taking component reusability to a whole new level. Be sure to check the docs for more in-depth details.

4. `.camel` prop modifier for specific camel-case HTML attributes

There are times when the HTML requires certain attributes to be written in camel case. Consider this example:

<!-- Svg.vue -->
<svg :view-box="viewBox">
  <circle cx="0" cy="0" r="50"/>
</svg>

viewBox was written in kebab-case because it is recommended for props by the styleguide. I thought Vue would know and convert it back to camel case anyway.

Well, it won't! It will be rendered as-is. You have to specifically tell Vue that the attribute needs to be in camel case when rendered. You can fix that with .camel:

<!-- Svg.vue -->
<svg :view-box.camel="viewBox">
  <circle cx="0" cy="0" r="50"/>
</svg>

The viewBox will be rendered properly in the HTML.

5. `v-once` directive for cheap, static content in templates

Static contents that won't ever change can be optimized by adding v-once on the root of the content, so that it is only rendered once regardless. The docs says it all.

I think this is one of the least mentioned features in Vue, because I don't think static content has ever come as major performance bottlenecks among Vue users. But, if you're interested, you can use them and let me know how it goes. Or, if maybe anyone has gained any significant performance improvements with v-once, let me know as well, I would love to learn.

Notable mentions

I'd like to also mention v-model which is a data communication model in-between parent and child, and <transition> which is a built-in component for transitioning between elements, but I think each deserves its own article due to their robustnesses and the details to cover. Stay tuned!

Of course, I'm not saying JSX can't do what Vue does. I think with JSX, anything is possible, since it's just Javascript. The point of the article is more towards the ease of using Vue's built-ins to achieve what JSX can do (or better?). JSX has its own beauty, especially the type-checking, that I must say. In other news, you can still use JSX with Vue!

By the way, if you have your own favorite Vue tips that aren't covered here, or if you have any feedback on the tips, do share it below in the comments. Also, these tips are already covered in their official docs, just thought I'd share with my own use cases.

Thank you for reading!

Cover image by Jeffrey Hamilton on Unsplash.

What is that one tool/stack/framework that you have no interest with despite the popularity?

briwa — Sat, 08 Jun 2019 14:37:42 +0000

In the tech world, there's always a plethora of popular tools that have been around for some time, but some people including me just don't have the time/capacity/resource/insert-reason-here to try it out.

For me, it's Docker. Most repos now have a way to setup with Docker and infra services such as AWS or Digital Ocean also provide integrations with Docker. The hype is still going strong as of now and people are starting to use Docker in development as well. However, the effort of running it in development just doesn't justify the gain. Maybe it's great on production, but I have been putting up static sites as of late. I've got no time to invest on this I guess, maybe someday when I need them.

How about you all? I'm curious if people here at dev.to is more like the type of people who would always be trying out (or master) the popular ones, or maybe more like me, stick to the usual until it's necessary to try out popular ones.

How strict is Typescript's strict mode?

briwa — Sat, 01 Jun 2019 19:19:47 +0000

I started out writing code in Javascript without proper typing. When I switched to Typescript, I migrated my code without turning the strict mode on because I knew that the typing refactor was going to be too much to handle, and I should focus on passing the unit tests first.

Even without the strict mode, it was already a shift of paradigm because you have to specifically define most of the things unlike Javascript. I thought I've already strict enough with my types back then. But how strict is strict mode?

According to the docs, when Typescript strict mode is set to on, it will validate your code using the strict type rules under the 'strict' family to all files in the project. The rules are:

noImplicitAny
noImplicitThis
strictNullChecks
strictPropertyInitialization
strictBindCallApply
strictFunctionTypes

These are some of the lessons I learned when I bumped into these rules.

1. `noImplicitAny`

This rule disallows variables or function arguments to have an implicit any type. Consider this example:

// Javascript/Typescript non-strict mode
function extractIds (list) {
  return list.map(member => member.id)
}

Looking at the code, list can be anything. Sure, from the .map you would think that it is an array of members, and the member has property called id but there isn't anything that specifically defines that. This is why it is an error in strict mode.

// Typescript strict mode
function extractIds (list) {
  //              ❌ ^^^^
  //                 Parameter 'list' implicitly has an 'any' type. ts(7006)
  return list.map(member => member.id)
  //           ❌ ^^^^^^
  //              Parameter 'member' implicitly has an 'any' type. ts(7006)
}

A fixed version would be:

// Typescript strict mode
interface Member {
  id: number
  name: string
}

function extractIds (list: Member[]) {
  return list.map(member => member.id)
}

Another common code that you might see in the wild:

// Typescript strict mode
function onChangeCheckbox (e) {
  //                    ❌ ^
  //                       Parameter 'e' implicitly has an 'any' type. ts(7006)
  e.preventDefault()
  const value = e.target.checked
  validateCheckbox(value)
}

You can use some of the global types defined by the Typescript itself for, in this case, browser-specific types:

// Typescript strict mode
interface ChangeCheckboxEvent extends MouseEvent {
  target: HTMLInputElement
}

function onChangeCheckbox (e: ChangeCheckboxEvent) {
  e.preventDefault()
  const value = e.target.checked
  validateCheckbox(value)
}

Do note that it would also throw an error if you import libraries that has no type definitions, because that would imply that the imported library has an any type.

// Typescript strict mode
import { Vector } from 'sylvester'
//                  ❌ ^^^^^^^^^^^
//                     Could not find a declaration file for module 'sylvester'.
//                     '/foo/node_modules/sylvester/lib/node-sylvester/index.js' implicitly has an 'any' type.
//                     Try `npm install @types/sylvester` if it exists
//                     or add a new declaration (.d.ts) file containing `declare module 'sylvester';` ts(7016)

It can be a bottleneck in your project since you might end up having to write that type definitions yourself if there isn't any, but having all types defined should've been the right thing to do anyway, at least in strict mode.

2. `noImplicitThis`

This rule disallows this context to be implicitly defined. Consider this example:

// Javascript/Typescript non-strict mode
function uppercaseLabel () {
  return this.label.toUpperCase()
}

const config = {
  label: 'foo-config',
  uppercaseLabel
}

config.uppercaseLabel()
// FOO-CONFIG

For someone who's been writing Javascript, it is known that this refers to the config object, so this.label would just be retrieving config.label, which is why this code works. However, referring to this on a function can be ambiguous.

// Typescript strict mode
function uppercaseLabel () {
  return this.label.toUpperCase()
  //  ❌ ^^^^
  //     'this' implicitly has type 'any' because it does not have a type annotation. ts(2683)
}

If we run uppercaseLabel alone, it would throw an error because this context is not on config anymore, hence the error because label is undefined.

One way to fix it is to avoid using this on a function without a context:

// Typescript strict mode
const config = {
  label: 'foo-config',
  uppercaseLabel () {
    return this.label.toUpperCase()
  }
}

Typescript won't even complain on this because all types are inferred properly. Or, even better, write the interface, so that all types are now defined instead of inferred.

// Typescript strict mode
interface MyConfig {
  label: string
  uppercaseLabel: (params: void) => string
}

const config: MyConfig = {
  label: 'foo-config',
  uppercaseLabel () {
    return this.label.toUpperCase()
  }
}

3. `strictNullChecks`

This rule validates the possibility of values returning null or undefined. Consider this example:

// Javascript/Typescript non-strict mode
function getArticleMetaById (articles: Article[], id: string) {
  const article = articles.find(article => article.id === id)
  return article.meta
}

Now, of course I would have checked the code first in the browser if it works (and it did). However, in strict mode, Typescript would remind me that there are chances that .find would return undefined when none of the ids in the responses would match the given id.

// Typescript strict mode
function getArticleMetaById (articles: Article[], id: string) {
  const article = articles.find(article => article.id === id)
  return article.meta
  //  ❌ ^^^^^^^
  //     Object is possibly 'undefined'. ts(2532)
}

This would actually broaden my code specification so that now I have to actually handle error cases as well, which should've been done in the first place.

// Typescript strict mode
function getArticleMetaById (articles: Article[], id: string) {
  const article = articles.find(article => article.id === id)
  if (typeof article === 'undefined') {
    throw new Error(`Could not find an article with id: ${id}.`)
  }

  return article.meta
}

4. `strictPropertyInitialization`

This rule validates properties in a class to be initialized either inside a constructor function or already defined before constructed. Consider this example:

// Javascript
class Student {
  constructor (grade, lessons) {
    this.grade = grade
    this.lessons = lessons.filter(lesson => lesson.grade <= grade)
  }

  setRedoLessons (lessons) {
    this.redoLessons = lessons
  }
}

With Typescript, all class instance properties can be defined properly.

// Typescript non-strict mode
interface Lesson {
  title: string
  grade: number
}

class Student {
  private grade: number
  private lessons: Lesson[]
  private redoLessons: Lesson[]
  private greetingType: string
  constructor (grade: number, lessons: Lesson[]) {
    this.grade = grade
    this.lessons = lessons.filter(lesson => lesson.grade <= grade)
  }

  setRedoLessons (lessons: Lesson[]) {
    this.redoLessons = lessons
  }
}

However, at this point you couldn't tell whether there is a property that isn't defined either in the constructor function or in some method. I don't know if you noticed but in the previous code I sneaked in a property that meets such criteria.

// Typescript non-strict mode
interface Lesson {
  title: string
  grade: number
}

class Student {
  private grade: number
  private lessons: Lesson[]
  private redoLessons: Lesson[]
  private greetingType: string // 👀 This is undefined, not used and there's no error!
  constructor (grade: number, lessons: Lesson[]) {
    this.grade = grade
    this.lessons = lessons.filter(lesson => lesson.grade <= grade)
  }

  setRedoLessons (lessons: Lesson[]) {
    this.redoLessons = lessons
  }
}

In strict mode, it actually throws errors on all undefined properties not defined in the constructor.

// Typescript strict mode
interface Lesson {
  title: string
  grade: number
}

class Student {
  private grade: number
  private lessons: Lesson[]
  private redoLessons: Lesson[]
  //   ❌ ^^^^^^^^^^^
  //      Property 'redoLessons' has no initializer and is not definitely assigned in the constructor. ts(2564)
  private greetingType: string
  //   ❌ ^^^^^^^^^^^^
  //      Property 'greetingType' has no initializer and is not definitely assigned in the constructor. ts(2564)
  constructor (grade: number, lessons: Lesson[]) {
    this.grade = grade
    this.lessons = lessons.filter(lesson => lesson.grade <= grade)
  }

  setRedoLessons (lessons: Lesson[]) {
    this.redoLessons = lessons
  }
}

This helps you review the code and see whether the properties are indeed being used in places other than the constructor. If it is, you can put an ! on it and simply remove those who aren't.

// Typescript strict mode
interface Lesson {
  title: string
  grade: number
}

class Student {
  private grade: number
  private lessons: Lesson[]
  private redoLessons!: Lesson[]
  constructor (grade: number, lessons: Lesson[]) {
    this.grade = grade
    this.lessons = lessons.filter(lesson => lesson.grade <= grade)
  }

  setRedoLessons (lessons: Lesson[]) {
    this.redoLessons = lessons
  }
}

However, I would recommend to either set it to a default value if it's not defined in the constructor as a good practice, otherwise it would be forever undefined until it is set (unless that is intentional).

5. `strictBindCallApply`

This rule validates the usage of bind, call or apply as defined in the function. Consider this example:

// Typescript without strict mode
function sum (num1: number, num2: number) {
  return num1 + num2
}

sum.apply(null, [1, 2])
// 3

Maybe a mistake is made, thinking that the sum can take in more than two arguments. When the code is run, there is no error thrown on Typescript and in your environment (browser, perhaps).

// Typescript non-strict mode
function sum (num1: number, num2: number) {
  return num1 + num2
}

sum.apply(null, [1, 2, 3])
// Still 3...?

The only way to know if it's a mistake is when the code is tested manually or in a unit test. In strict mode, you can spot this even before that:

// Typescript strict mode
function sum (num1: number, num2: number) {
  return num1 + num2
}

sum.apply(null, [1, 2, 3])
//           ❌ ^^^^^^^^^
//              Argument of type '[number, number, number]' is not assignable to parameter of type '[number, number]'.
//                Types of property 'length' are incompatible.
//                  Type '3' is not assignable to type '2'. ts(2345)

Then it might be a good time to rethink of the sum function design.

// Typescript strict mode
function sum (...args: number[]) {
  return args.reduce<number>((total, num) => total + num, 0)
}

sum.apply(null, [1, 2, 3])
// 6

6. `strictFunctionTypes`

Unfortunately, I have yet to find the use case of this rules in my code so far, so I can't comment much on it. You can always check out the release notes for strictFunctionTypes on the docs. If anyone has a use case to share, let me know!

If you want to take Typescript restrictions to a different level, I recommend using tslint, though I would say some of the rules are based on preferences, but there are a lot of useful ones. Or, avoid bikeshedding by choosing a standard such as gslint or tslint-config-standard.

I hope you find this article useful! Thanks for reading.

Cover image by by Mark Duffel on Unsplash.

My "Whoa, I didn't know that!" moments with Jest

briwa — Sun, 26 May 2019 15:41:49 +0000

Jest has always been my go-to unit testing tool. It is so robust I'm starting to think that I've always been underutilizing it. Although the tests are passing, over time I've refactored my test here and there because I didn't know Jest can do that. It's always a different code every time I checked back Jest docs.

So, I'm going to share some of my favorite tricks with Jest that some of you might already know because you didn't skip reading the docs like me (shame on me), but I hope this helps those who did!

FWIW, I'm using Jest v24.8.0 as the reference, so be aware if certain things don't work on the Jest version you're currently using. Also, the examples do not represent the actual test code, it is just merely a demonstration.

#1. `.toBe` vs `.toEqual`

All these assertions looked good to me at first:

expect('foo').toEqual('foo')
expect(1).toEqual(1)
expect(['foo']).toEqual(['foo'])

Coming from using chai to do equality assertions (to.equal), it's just natural. In fact, Jest wouldn't complain and these assertions are passing as usual.

However, Jest has .toBe and .toEqual. The former is used to assert equality using Object.is, while the latter is to assert deep equality on objects and arrays. Now, .toEqual has a fallback to use Object.is if it turns out that it doesn't need deep equality, such as asserting equalities on primitive values, which explains why the earlier example was passing just fine.

expect('foo').toBe('foo')
expect(1).toBe(1)
expect(['foo']).toEqual(['foo'])

So, you can skip all the if-elses in .toEqual by using .toBe if you already know what kind of values you're testing.

A common mistake is that you would be using .toBe to assert equality on non-primitive values.

expect(['foo']).toBe(['foo'])

If you look at the source code, when .toBe fails, it would try to see if you are indeed making that mistake by calling a function that is used by .toEqual. This could be a bottleneck when optimizing your test.

If you are sure that you are asserting primitive values, your code can be refactored as such, for optimization purpose:

expect(Object.is('foo', 'foo')).toBe(true)

Check out more details in the docs.

#2. More befitting matchers

Technically, you can use .toBe to assert any kind of values. With Jest, you can specifically use certain matchers that would make your test more readable (and in some cases, shorter).

// 🤔
expect([1,2,3].length).toBe(3)

// 😎
expect([1,2,3]).toHaveLength(3)

const canBeUndefined = foo()

// 🤔
expect(typeof canBeUndefined !== 'undefined').toBe(true)

// 🤔
expect(typeof canBeUndefined).not.toBe('undefined')

// 🤔
expect(canBeUndefined).not.toBe(undefined)

// 😎
expect(canBeUndefined).toBeDefined()

class Foo {
  constructor(param) {
    this.param = param
  }
}

// 🤔
expect(new Foo('bar') instanceof Foo).toBe(true)

// 😎
expect(new Foo('bar')).toBeInstanceOf(Foo)

These are just a few I picked from a long list of Jest matchers in the docs, you can check out the rest.

#3. Snapshot testing on a non-UI elements

You might have heard about snapshot testing in Jest, where it helps you monitor changes on your UI elements. But snapshot testing is not limited to that.

Consider this example:

const allEmployees = getEmployees()
const happyEmployees = giveIncrementByPosition(allEmployees)

expect(happyEmployees[0].nextMonthPaycheck).toBe(1000)
expect(happyEmployees[1].nextMonthPaycheck).toBe(5000)
expect(happyEmployees[2].nextMonthPaycheck).toBe(4000)
// ...etc

It would be tedious if you have to assert more and more employees. Also, if it turns out that there are more assertions to be done for each employee, multiple the number of the new assertions with the employee count and you get the idea.

With snapshot testing, all of these can be done simply as such:

const allEmployees = getEmployees()
const happyEmployees = giveIncrementByPosition(allEmployees)

expect(happyEmployees).toMatchSnapshot()

Whenever there are regressions, you would exactly know which tree in the node that doesn't match the snapshot.

Now, this handiness comes with a price: it is more error-prone. There are chances that you wouldn't know that the snapshot is in fact wrong and you would end up committing it anyway. So, double check your snapshot as if it is your own assertion code (because it is).

Of course there is more to it on snapshot testing. Check out the full docs.

#4. `describe.each` and `test.each`

Have you written some test that is somewhat similar to this?

describe('When I am a supervisor', () => {
  test('I should have a supervisor badge', () => {
    const employee = new Employee({ level: 'supervisor' })

    expect(employee.badges).toContain('badge-supervisor')
  })

  test('I should have a supervisor level', () => {
    const employee = new Employee({ level: 'supervisor' })

    expect(employee.level).toBe('supervisor')
  })
})

describe('When I am a manager', () => {
  test('I should have a manager badge', () => {
    const employee = new Employee({ level: 'manager' })

    expect(employee.badges).toContain('badge-manager')
  })

  test('I should have a manager level', () => {
    const employee = new Employee({ level: 'manager' })

    expect(employee.level).toBe('manager')
  })
})

That is painstakingly repetitive, right? Imagine doing it with more cases.

With describe.each and test.each, you could condense the code as such:

const levels = [['manager'], ['supervisor']]
const privileges = [['badges', 'toContain', 'badge-'], ['level', 'toBe', '']]

describe.each(levels)('When I am a %s', (level) => {
  test.each(privileges)(`I should have a ${level} %s`, (kind, assert, prefix) => {
    const employee = new Employee({ level })

    expect(employee[kind])[assert](`${prefix}${level}`)
  })
})

However, I have yet to actually use this in my own test, since I prefer my test to be verbose, but I just thought this was an interesting trick.

Check out the docs for more details on the arguments (spoiler: the table syntax is really cool).

#5. Mocking global functions once

At some point you would have to test something that depends on a global function on a particular test case. For example, a function that gets the info of the current date using Javascript object Date, or a library that relies on it. The tricky part is that if it's about the current date, you can never get the assertion right.

function foo () {
  return Date.now()
}

expect(foo()).toBe(Date.now())
// ❌ This would throw occasionally:
// expect(received).toBe(expected) // Object.is equality
// 
// Expected: 1558881400838
// Received: 1558881400837

Eventually, you had to override Date global object so that it is consistent and controllable:

function foo () {
  return Date.now()
}

Date.now = () => 1234567890123

expect(foo()).toBe(1234567890123) // ✅

However, this is considered a bad practice because the override persists in between tests. You won't notice it if there's no other test that relies on Date.now, but it is leaking.

test('First test', () => {
  function foo () {
    return Date.now()
  }

  Date.now = () => 1234567890123

  expect(foo()).toBe(1234567890123) // ✅
})

test('Second test', () => {
  function foo () {
    return Date.now()
  }

  expect(foo()).not.toBe(1234567890123) // ❌ ???
})

I used to 'hack' it in a way that it won't leak:

test('First test', () => {
  function foo () {
    return Date.now()
  }

  const oriDateNow = Date.now
  Date.now = () => 1234567890123

  expect(foo()).toBe(1234567890123) // ✅
  Date.now = oriDateNow
})

test('Second test', () => {
  function foo () {
    return Date.now()
  }

  expect(foo()).not.toBe(1234567890123) // ✅ as expected
})

However, there's a much better, less hacky way to do it:

test('First test', () => {
  function foo () {
    return Date.now()
  }

  jest.spyOn(Date, 'now').mockImplementationOnce(() => 1234567890123)

  expect(foo()).toBe(1234567890123) // ✅
})

test('Second test', () => {
  function foo () {
    return Date.now()
  }

  expect(foo()).not.toBe(1234567890123) // ✅ as expected
})

In summary, jest.spyOn spies on the global Date object and mock the implementation of now function just for one call. This would in turn keep Date.now untouched for the rest of the tests.

There is definitely more to it on the topic of mocking in Jest. Do check out the full docs for more details.

This article is getting longer, so I guess that's it for now. These are barely scratching the surface of Jest's capabilities, I was just highlighting my favorites. If you have other interesting facts, let me know as well.

And also, if you used Jest a lot, check out Majestic which is a zero-config GUI for Jest, a really good escape from the boring terminal output. I'm not sure if the author is in dev.to, but shout out to the person.

As always, thanks for reading my post!

Cover image from https://jestjs.io/

A few tips I wish I could tell my younger self

briwa — Fri, 17 May 2019 18:26:58 +0000

TL;DR: Make your future self proud by making the right life choices.

I'm going to hit my six year mark in September as a web/frontend developer, which is probably relatively short compared to most of us here. Seeing how a few areas could have gone better, there are times when I wished I knew better back then.

Here are several tips that would have at least helped my younger self thrive better in the software engineering world. If you're like me six years ago, just getting your first job, maybe you should try some of these too! It's not anything tough or extreme, I promise.

1. Stay healthy

The reason why I put this first is because it's the most important aspect in my opinion. None of the rest of the tips would be relevant if I was not in a good shape: body, mind and soul.

I wasn't that active before I got into the field, but I didn't know that working life was such a life-changing environment. Sitting down 9-5 with full-blown aircon, not drinking water that much, burned out by the weekend and sleep too much. These were okay at first, but the effect would definitely build up over time.

A few stay-healthy tips: drink water, maintain a good posture while at work, get enough sleep, stay active by doing exercise twice a week. Not just physically, though, mentally as well: talk/write about it instead of resorting to too much eating, go out more, explore new places, join communities. You get the idea.

2. Learn proper English

English isn't my first language, and I only started using it everyday when I got my job. A lot of people would give me a pass since I'm not a native speaker, and I've been surrounded by the nicest people at work who would try their best to understand what I said.

However, these nice things were rendered useless the moment I stepped into the outside world. Open source communities, hackatons, dev conventions. I was technically mute outside of work.

These could have been avoided by learning to speak English properly and start practicing. Writing, reading, listening, speaking. And most importantly, I should speak not the way I would understand, but speak the way people would understand. Subtle, but it is really two different things to me.

PS: If you found any grammar/spelling errors in this article, let me know! That would mean a whole lot.

3. Contribute to open source projects

There were times when I had to resort to hacks (or prefer hacks), not exploring other options or not following best practices, just because projects had to be completed asap. This created a mindset that my practices are good enough because it works and I should keep doing it (Narrator: He shouldn't).

Obviously, I didn't know any better. Had I learned about open source, the majority of the popular projects are using a whole lot better code standards than mine, because it was maintained and contributed by more experienced, skilled people than me.

It is really a good place to learn. Contributing to open source validates the practices that I have been doing at work, so that I would eventually get off my high horse and be a student again. I could also share what I know, which could be valuable for others to learn from (or to avoid).

Ultimately, contributing to open source means giving back to the community. I've been helped out a lot by open source libraries, it's only fair if I help them out as well.

4. Public speaking

I've mentioned writing, but it shouldn't be limited to just that. There are events, meetups, or even dev conventions that I could join as a speaker and share what I know. The benefit is three-fold: it improves my public speaking skill, it validates my work or ideas, and sharing is always good after all.

I've always looked up to great speakers and how cool they were on stage, doing live coding and cracking up jokes. I thought it would be impossible for me to do the same, but I realized that I have to start small anyway. Writing is a good start. Seek for local meetups and start from there. Do a youtube tutorial or a podcast. Anything that works to get me to that stage someday.

5. Breathe and have fun

One time I was trying to find a cause for a bug on a long piece of code that has no comments and no test. I talked to myself, 'What am I doing here...'. But really though, often time I focused way too much on the not-so-fun part of the job and this could spiral down into something that is way worse than just bugs.

Of course, there is no such thing as perfect job, but that doesn't mean I would suffer forever. Breathe and move on. If things aren't ideal and it can't be fixed, there's always other projects to do. Don't forget that the fun was the one that got me into this field after all.

Conclusion

I wasn't even sure if my younger self even considered any of these back then because I was way too deep into my comfort zone. No wake up calls. But it's never too late to make a change, in fact I only started doing some of these tips a few months back, and I've already felt good seeing how I am already better than myself, say, a month ago.

Hope you find these tips useful. And as always, thank you for reading this article!

Cover photo by Ilinca Roman on Unsplash.

Simple ways to improve code readability

briwa — Sat, 11 May 2019 14:58:50 +0000

TL;DR: It might be obvious to you, but not to others.

Why?

More often than not, I used to think that my code is just for me (Narrator: It's not). Whether I'm coding at work or coding for my own side project, at some point someone else will look into the code and try to understand how it works. The last thing you want to happen is them spending too much time doing it.

A little disclaimer: this isn't about rewriting your code and using a totally different programming paradigm (cuz FP the best P), or being overly verbose with variable names and comments. I'll save that for another time. I find that even the smallest changes in the way I write the code could actually help improving the readability. Small enough for a good start.

In the wild

Let's consider a few code examples.

#1

// When the id is in the list, retrieve by id
if (ids.indexOf(id) !== -1) {
  retrieveItemById(id);
}

This code works, obviously. I coded it, merged it, went for lunch, and mostly forgot about it. Then someone else reads this code:

If the index of the id in the list of ids does not equal to minus one, retrieve the item by id.

That person mutters, Well, that's one way to put it.

See, this should be avoidable. That person should never have said that. Anyway, let's take a look at how I should fix it.

It is true that .indexOf will return -1 if the value is not in the list, but that isn't what I wanted to say, right? I wanted to do something when the id is in the list of ids, instead of do something when the id is not not in the list of ids.

It is subtle, but the code in my opinion reads better this way:

// When the id is in the list, retrieve by id
if (ids.indexOf(id) >= 0) {
  retrieveItemById(id);
}

Heck, I could throw in some ES6 magic and the readability is now times 3000:

// When the id is in the list, retrieve by id
if (ids.includes(id)) {
  retrieveItemById(id);
}

But wait, there's more!

#2

// See if any of the results has an error
const isSuccess = results.filter((result) => result.error === true).length === 0;

Now, this is similar to the previous one. If the whole ordeal was whether there are no errors in the results, it should be a statement that returns a boolean. Using .filter then checking the array length makes it longer to read and understand the code.

// See if any of the results has an error
const isSuccess = !results.some((result) => result.error === true)

However, putting a negation in front of the statement makes the code less clearer.

It is a success when not some of the results have an error.

An improved version would be:

// See if any of the results has an error
const isSuccess = results.every((result) => result.error !== true)

The code now reads:

It is a success when every result doesn't have an error.

.some and .every have benefits over .filter because it will stop iterating through the array if the statement is true for the former, and false for the latter. So, even from an efficiency standpoint, .some and .every are better than .filter in this context.

Last one, I promise.

#3

// Only ship item that isn't broken and expired
if (!item.broken && !item.expired) {
  shipItem(item);
}

Over time, we noticed that we've been shipping items that aren't in stock. Fine....

// Only ship item that isn't broken, expired, and stock is not zero (duh)
if (!item.broken && !item.expired && item.stock !== 0) {
  shipItem(item);
}

I mean, it looks good, right? Right? Wrong.

Again, what I meant isn't exactly ship the item if the stock isn't not there, but ship the item if the stock is there.

It could be that I was following the pattern of the rest of the logic (!item.broken, !item.expired) and subconsciously went for another negation, but for this case, it is better to read if it was done without negation.

// Only ship item that isn't broken, expired, and stock is there
if (!item.broken && !item.expired && item.stock > 0) {
  shipItem(item);
}

Conclusion

These examples are really simple, easy-to-avoid issues. And of course, there are other different ways to improve code readability. My main point is that we should try to stop having the mindset of 'my code works and I understand it fine'. Coding isn't essentially just to make it work, it's also to educate others on how (and why) it works.

To me, a good code is similar to how people describe a good UX or a good joke: If you have to explain it, it might not be that good. It's other people that defines whether your code is easy to understand, it shouldn't be you. So, whenever possible, second-guess your code and improve them so that others don't have to.

Of course, this doesn't mean that you would have to go down to a level where a biology major should understand your code. I think what makes a good code is also the balance between making it understandable and having to explain everything. And that takes experience.

Thanks for reading (my first article, btw).

Cover image by Nicolas Thomas on Unsplash.

DEV Community: briwa

When you try your best (at what you're already good at) but you don't succeed...

The League of (Five) Extraordinary Javascript Resources

1. Untrusted (https://alexnisnevich.github.io/untrusted/)

2. https://regexr.com/ (https://github.com/gskinner/regexr)

3. https://dwitter.net/ (https://github.com/lionleaf/dwitter)

4. https://observablehq.com/ (https://github.com/observablehq)

5. Jake Archibald - In the Loop (https://www.youtube.com/watch?v=cCOL7MC4Pl0)

A Series of My Unfortunate Mistakes (When Writing Tests)

1. Not keeping the test simple

2. Not maintaining a clean state on each tests

3. Not asserting the state properly

4. Not structuring the tests properly

5. Not trusting the libraries you're using

(Fantastic) XY Problems and How to Avoid Them

How are technical decisions being made in your company?

Me: "I tested and it works, why do I have to write tests?"

From JSX to Vue: my favorite templating tips

1. v-if, v-else and v-else-if for conditional rendering

2. <component> tag to avoid repetitions on similar components

3. <slot> tag for shared component reusability

4. .camel prop modifier for specific camel-case HTML attributes

5. v-once directive for cheap, static content in templates

Notable mentions

What is that one tool/stack/framework that you have no interest with despite the popularity?

How strict is Typescript's strict mode?

1. noImplicitAny

2. noImplicitThis

3. strictNullChecks

4. strictPropertyInitialization

5. strictBindCallApply

6. strictFunctionTypes

My "Whoa, I didn't know that!" moments with Jest

#1. .toBe vs .toEqual

#2. More befitting matchers

#3. Snapshot testing on a non-UI elements

#4. describe.each and test.each

#5. Mocking global functions once

A few tips I wish I could tell my younger self

1. Stay healthy

2. Learn proper English

3. Contribute to open source projects

4. Public speaking

5. Breathe and have fun

Conclusion

Simple ways to improve code readability

Why?

In the wild

#1

#2

#3

Conclusion

1. `v-if`, `v-else` and `v-else-if` for conditional rendering

2. `<component>` tag to avoid repetitions on similar components

3. `<slot>` tag for shared component reusability

4. `.camel` prop modifier for specific camel-case HTML attributes

5. `v-once` directive for cheap, static content in templates

1. `noImplicitAny`

2. `noImplicitThis`

3. `strictNullChecks`

4. `strictPropertyInitialization`

5. `strictBindCallApply`

6. `strictFunctionTypes`

#1. `.toBe` vs `.toEqual`

#4. `describe.each` and `test.each`