What are the most game-changing resources on automated testing you've seen?

testing
resources

#1

Hi AQ!

For automated testing, what are the most game-changing resources you’ve read? I automated-test a lot of my Go and use a lot of Testify to write the tests (https://github.com/stretchr/testify) with assertions and suites, but I’m not sure if my techniques really have a name, so I want to see what testing styles are out there, especially as I’m doing more JavaScript and building up my testing skills there


#2

Btw here’s an overview of the JS testing software out there so far https://medium.com/welldone-software/an-overview-of-javascript-testing-in-2018-f68950900bc3


#3

Hi canteloupeantelope!

Oh boy, this is my favorite topic!

Test-Driven Development By Example (a book by Kent Beck) is an excellent starting point.

If you’re building on top of (or within) existing code bases, especially ones that don’t have many tests or don’t lend themselves to testing, you’ll get a lot out of the book Working Effectively with Legacy Code by Michael Feathers. I leaned heavily on techniques I learned from that book while developing my testing style for mobile frameworks (Android, iOS).


#4

To continue from Test-Driven Development By Example, which is more about unit test sized TDD,
I would recommend Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce, which showed me how do you do TDD when creating bigger software. These books use Java as their language, so they don’t exactly translate to modern JavaScript frameworks. They don’t share the object-oriented paradigm with Java, but just the ideas and the way of thinking presented in the books have helped me with writing my own tests.


#5

This might be a little of a tangent from the canteloupantelope’s OP, but “snapshot testing” with Jest has been amazing for UI development. I have also seen it used for non-UI testing, too, so it is versatile in that sense.

For our team, snapshot testing has allowed us to make sure that the DOM that is generated is the expected output. This has been amazing for me, because I can simply look at a diff to know if the UI output has changed or not. I still test as a user, in the browsers, but it probably reduces the amount of times I need to context switch to the browser and inspect the DOM there.

In addition, we use CSS-in-JS, and so the styles are actually part of the same snapshot as the DOM output, so it is twice as effective in ensuring that the UI output is what it should be.


#6

+1 (or as many as I’m allowed to give :slight_smile:) vote for Working Effectively with Legacy Code. The most common stumbling block for test adoption, in my experience, is what to do with the bundle of existing, untested code. I’ve recommended this book hundreds of times and almost everybody comes back with stories of how it helped them get going.


#7

Looks like my bookstore shopping list just grew a little. :slight_smile:


#8

Apart from reading, you can learn a lot about the quality of your tests through mutation testing. I use pitest for Java, but it looks like there are quite a few options for golang too.