How can I learn more about testing?

[xlgmokha]

The first book that I read about test driven development (tdd) was Test-driven Development: By Example. I was a .NET developer back then so I read the NUnit documentation and started to try it out at work. I instantly fell in love with the feedback cycle. Red, green, refactor. Red, green, refactor. Writing tests first allowed me to learn languages, explore API's, build things that I had no idea how we were going to build and it was fun.

TDD can be explained like this.

1. Write a failing test.
2. Make it pass.
3. Refactor the code.

By writing a failing test first, it forces you to think about the API that you're about to build from the perspective of a client component. This inherently ensures that the code that you end up writing to satisfy the test has to be testable, which is usually a good quality. It's also a great design tool because it allows you to experiment with different ideas before you commit to one.

The make it pass step gives you permission to write awful, horrendous, disgusting code. As long as you can make the test pass. This is nice because it allows you to focus on one small thing at a time, rather than worrying about every possible edge case in the beginning.

Refactor the code is the fun part. Here's where you get to use different design principles to improve the smell of your code. Refactoring is a must read to get better at this.

As you begin to add more and more tests, this tends to build more and more confidence to make changes to the code. Well written tests allows you make changes without needing to worry about knowing the details of the entire codebase. Well written tests have a nice side affect of also documenting the behaviour of the code. Enter BDD.

I believe it was in User Stores Applied where I was introduced to the test pyramid. The idea presented was that there's many layers of tests that you can write.

       -----------
      /  manual   \
     /-------------\
    / functional/ui \
   /-----------------\
  / integration tests \
 /---------------------\
/     unit test         \
-------------------------

The bulk of your tests should be unit tests because they provide fast feedback and are isolated. It tests small units of code. You would then have integration tests to test across component boundaries to make sure that things actually work together. Functional/acceptance/ui tests are usually the slowest running tests and can be quite brittle to run. So you tend to have the least amount of these but they test things from an end users perspective e.g. open a browser, login, click on button etc.
Your testing strategy should have a minimal amount of manual testing to verify the quality of your software.

There are lots of details to cover in each layer of the test pyramid but hopefully this provides some high level guidance on how to get started. Read the books mentioned above, write some code using your language and test runner of choice to practice and execute over and over.

Happy Hacking!

/cc @kirstybrews

[kirstybrews]

Thank you, @xlgmokha!! 🙏 Definitely going to look into these books. I also think this is great info to add to Lesson 3.

Will we need to add tests to the SparkleHub project at some point? If so, I could try my hand at writing some tests for that.

[xlgmokha]

Will we need to add tests to the SparkleHub project at some point?

It has some tests but they are not comprehensive. Please add tests or any other changes that you would like to see.