I think my testing is pretty standard. Both in approach and amount.
But I’ve been more focused on integration tests lately as part of my development cycle. First unit tests for the small things like the mappings we tend to do so much of. Then the integration tests as a key part of my actual development. And then lastly I incorporate it into my application without much worry. Using this code in the application is now the least of my work because I already know all of the processes already work as expected. It’s just a matter of wiring it up correctly.
Unit tests are unit tests. But the part you may be interested in is that integration test for me lately have been very much literally “how I develop”. I encapsulate units of whatever process is at hand this push into my test. I might ingest documents from db, file, or api, and examine them with the debugger and see what I have available, what work that needs to be done elsewhere. Move forward and maybe use all of the mappings I mentioned (already unit tested), manipulate / transform / lookup (already unit tested). Move forward and examine the results of the ingest /export / process from whatever service is providing that feature.
I consider my integration tests to be anything that performs multiple actions for components that are already unit tested, maybe can handle an expected exception, maybe requires another component of the app to be running.
It’s definitely not TDD. But if it’s something QA is gonna analyze with excel or some validator api then it’s been unit tested. If it’s a process I want robustness out of, it’s been integration tested.
I think the switch for me happened when I decided not to create “that little console app” to wrap my work and aid development; and instead just write a test. I’m sure someone might critique the heck out of my thoughts here. But it’s working.
Unit tests for complex logical or algorithmic code with simple interfaces.
Hermetic end to end tests for the rest.
I think my testing is pretty standard. Both in approach and amount.
But I’ve been more focused on integration tests lately as part of my development cycle. First unit tests for the small things like the mappings we tend to do so much of. Then the integration tests as a key part of my actual development. And then lastly I incorporate it into my application without much worry. Using this code in the application is now the least of my work because I already know all of the processes already work as expected. It’s just a matter of wiring it up correctly.
Unit tests are unit tests. But the part you may be interested in is that integration test for me lately have been very much literally “how I develop”. I encapsulate units of whatever process is at hand this push into my test. I might ingest documents from db, file, or api, and examine them with the debugger and see what I have available, what work that needs to be done elsewhere. Move forward and maybe use all of the mappings I mentioned (already unit tested), manipulate / transform / lookup (already unit tested). Move forward and examine the results of the ingest /export / process from whatever service is providing that feature.
I consider my integration tests to be anything that performs multiple actions for components that are already unit tested, maybe can handle an expected exception, maybe requires another component of the app to be running.
It’s definitely not TDD. But if it’s something QA is gonna analyze with excel or some validator api then it’s been unit tested. If it’s a process I want robustness out of, it’s been integration tested.
I think the switch for me happened when I decided not to create “that little console app” to wrap my work and aid development; and instead just write a test. I’m sure someone might critique the heck out of my thoughts here. But it’s working.