I recently did a survey among the developer-team of a client. I asked several points regarding their knowledge in software engineering generally, and experience regarding software quality specifically. This was done to be able to prepare my workshops for this client. Of course, I wouldn't want to talk about things they are already experts in.
The topic > 95% of the developers mentioned they would like to get guidance on and learn more about was: Testing. It didn't come to me as a surprise, because I worked with the team the last three months and I saw the code base.
Of course testing is a topic with many smaller subtopics. This team feels confident in being able to generally write a test. But they struggle in knowing what to test. This is an important distinction to make.
In my experience it gets easier to know what to test, when the system under test (SUT) is deliberately small. If you have a single class that does one thing, then it could be a bit easier to say what to test, then for a class that does 4 or more things.
Think about it: Imagine a bus (the thing that drives on streets and eats humans).
When you design software for the bus, you have to think about lots of things. The doors shouldn't close, when there is somebody just enterering/exiting the vehicle. The display that shows the next stops and the final destination needs to be updated after you just left a stop and head for the next one. The switches for the lights (inside and out) should work as expected. And millions of other things. I am no bus expert, if you haven't noticed yet…
Now think about one single component of the bus and its software: The sub-system that "reads" the name of the next stop. I will simplify again. If you know buses please cut me some slack (and please do tell me what I got wrong!).
All this subsystem does is to play the correct audio file that is "connected" to the next stop. It doesn't do this on it's own. It is synchronized with the display. So I imagine, there is an event that tells the display to update (and passes the data for the next stop). And this event tells the speakers-subsystem to play sound file
xyz.wav. Because that is the correct one for the next stop.
Your task is to write (a) test(s) for the speaker-subsystem. It is critical that the right file is played, because there are lots of people on the bus that have bad vision. If this is your task, please tell me: What do you test for?
I am awaiting your replies.