Re: Re: Unit Test

Post by iveqy

> The best way of using tests is not to test that the software does what it should do, but to make sure that it continues to do what it's supposed to do while being changed.

Yes, that is the purpose of tests. To make sure that what you expect the code to do is what it does. Not just not but in the future when you make changes. But What you're talking about...

> no don't test small simple functions, that's of no use. But when adding a feature, write a tests that show that that feature work.

... is system level testing. In my original response I described the difference between the two, and that the point of writing well thought out unit tests that work at the lowest level is that the total coverage area of your system level tests does not need to be hitting all edge cases. It is far easier to validate that your code checking password restrictions by running a test directly on the validation code. It is far more cumbersome to write the same coverage at the "As a user I should be able to login" system level test.

When writing communication systems there were scenarios where we knew many potential states of the system during failure. Getting the system into that specific state was extremely complex. To write tests at that level would have taken an enormous amount of effort. We could still test the happy path, and we could still test a few failure paths to make sure that failure handling occurred. We were able to make sure that the feature does what is asked of it. But the point of writing unit tests was to reduce the extreme complexity of those those higher level tests.

This is similar to how your QA team will perform UAT testing on what you expect to be a deliverable. They will look at the requirement, and attempt to come up with all of the possible happy and failure paths they can. But depending on the complexity and the ways the state of the system changes, they may not be able to cover everything due to the method and situation they are running. Not having a deep knowledge of the code means that they may not understand all possible edge cases. But the hope is that your unit tests pass, your system tests pass and when QA completes their testing all avenues of Verification testing have been completed. Often time bugs that make it all the way through this process have the highest likelihood of being found at a unit test level and as you move towards UAT they become more nuanced and difficult to replicate.

Sadly, most people skimp or completely skip out on unit testing. Even when its mandated by their development process. Especially when they write in languages that allow for rapid prototyping. As soon as they have something that works its pushed through the rest of the process. When I used to work on projects under the waterfall model, I scheduled a fair amount of time to create unit tests to follow TDD. For a project that may have 18 month development schedule I would create unit tests for a few weeks before even starting development. As I added functionality I could see the progress as more and more tests passed. I also knew that not only were my system level requirements "As a user..." were met, but I knew that all the technical needs, the scope and edge cases of all solutions to the requirements, all of these were being met. For a long time I was the sole developer, full time developer on those projects. And I was able to crank out a lot of code because I had my tests setup to verify that yes in fact the feature worked.

My original response

$ published: 2022-10-18 16:18 $

$ tags: programming $

-- CC-BY-4.0 jecxjo 2022-10-18

back