Good to chat with you again, Sir!
I’d like to explore some of the great points you made. While I believe unit tests can be valuable in the scenario you describe, I may not have the context or familiarity with a Fitbit to speak expertly about them.
I agree that integration tests can provide information about the Fitbit behavior while in use by a human. The primary purpose of integration tests are to explore and evaluate connectivity, configurations, and security. What I might consider is isolating human movements, services, and data synchronization. In my opinion, these items resolve themselves to just data.
Human movements generate data in the Fitbit and that data can be modeled for use in unit tests. Scenarios such as walking, running, sitting, typing, and other movements certainly have data signatures which can be used to explore Fitbit code behaviors.
With respect to a mobile application, I believe behaviors can be isolated and explored through unit tests. Isolation is a key testability component in supporting tests at that level. The same can be said for the website.
At an integration level, I start small. Perhaps we integrate the mobile application and the web site while providing mock data we used in unit testing. Or perhaps we integrate the mobile application and the Fitbit. My intent is to minimize the number of components so I can grow confidence before evaluating the mobile application, the web site, and the Fitbit together.
Not having a Fitbit, I’m not familiar with how it uses GPS and image information. These are sensors and sensors generate data. Might that data be useful in unit testing? I agree that the context would drive that conversation.
We see this all too often. I consider it a cultural artifact that should be addressed by Testing leadership.
Agreed. I also encourage testers to explore the boundaries of unit testing. I believe it is possible to have unit tests explore products a little more deeply given the tools and technologies available.