"Unit testing" reserved for automation?
-
Here we are back to making the "how to do it" easy, and re-creating the fragility problem that comes with having such a large and complex dependency (a whole database in your example).
As in a database engine? SQLite is a self-contained C library with a quite stable core API, and is small enough in footprint that I could realistically put it on the larger microcontrollers out there these days!
Now, if you're arguing that the test data is-a-dependency, that's a whole another ball of wax.
-
-
In this case, well...you're going to need the data to test what you've done one way or another -- so it's really an unavoidable dependency. Fortunately, it's a much easier dependency to manage than somebody else's code ever could be.
-
it's really an unavoidable dependency
Nope. The dependency is removed by making the data access layer trivial - and only do automated tests on the few parts of it that are necessarily slightly more complicated. All the non-trivial things are in higher layers and are all tested with mocked data.
Fortunately, it's a much easier dependency to manage
It's the second hardest to manage dependency there is. Third party black boxes are usually harder.
-
@tarunik said:
it's really an unavoidable dependency
Nope. The dependency is removed by making the data access layer trivial - and only do automated tests on the few parts of it that are necessarily slightly more complicated. All the non-trivial things are in higher layers and are all tested with mocked data.
Am I wooshing on something or is the mocked data exactly the test data is-a-dependency you describe higher up the thread?
It doesn't matter if you mock data for low level layers or high level layers. The mocked data you use to test is dependent on the thing your testing either way.
-
Am I wooshing on something or is the mocked data exactly the test data is-a-dependency you describe higher up the thread?
It doesn't matter if you mock data for low level layers or high level layers. The mocked data you use to test is dependent on the thing your testing either way.
A good example was that a setup routine would sometimes break due to schema changes unrelated to the functionality being tested. If this happened in code, the test suite would throw a bunch of compile errors and we would have them fixed in minutes, before the first test failed. We didn't know the sp tests failed until we ran them. After they failed, the structure of the setup code made it take longer to identify the problem and fix it. Even with the RedGate tool mentioned above, you would still have to go through some steps to regenerate the test data blob that would add to the time taken to get the test up and running.
Mocked data is easier a less complex dependency and is easier to test.
