This person is genius, he explains really well!! Thank you.
@CppCon
2 жыл бұрын
Glad you think so!
@volkerdr.milbrandt7692
3 жыл бұрын
Good introduction based on an existing project.
@hrnkas
3 жыл бұрын
I have one problem with most tutorials on how to introduce tests in legacy code. Almost all of them are testing an application that gets one input and produces one output. Sorry, but that is easy. Where is a video on how to introduce testing in windows MFC MDI application, where almost all components depend on each other; where there is no meaningful operation that does not include a query to the database? Where do I start with such legacy code? How to introduce regression tests in a non-deterministic application (meaning the same input does not always produce same output)?
@MarincaGheorghe
3 жыл бұрын
how can an input not produce same input ? If that happens how can you know the output is OK, even without tests ?
@georganatoly6646
3 жыл бұрын
it could be argued those kinds of tests aren't unit tests but integration or systems tests, and depending on the specific behaviors in test you might need to create in-memory database mocks all the way to mirroring full slices of the production environment in a cloud environment, say for example in Azure using Powershell scripts based on some configuration snapshot of the current production environment and testing the desired behavior against those
@EmmanuelIstace
3 жыл бұрын
"Working effectively with legacy code" by Michael Feather, you'll certainly love it, gl hf :)
@kuhluhOG
2 жыл бұрын
@@georganatoly6646 quite frankly, I prefer writing an in container test mock script (which e.g. sets up a database) to doing this in the C++ code from my experience easier to keep correct
@Alex-ez5qs
2 жыл бұрын
1. Not every code is well testable. When you write new code you have to ensure it will be testable - this is an essence of good design. When you deal with legacy code you may have to refactor it in order to produce proper unit tests. If refactoring can't be done, you may not unit test your code at all, or your tests will be ugly and fragile (any little change or refactoring may brake them). 2. If there are dependencies such as queries to databases you have to do the following. First, make sure those queries are all encapsulated in corresponding class and do not mess with other business logic. Second, create mocks for classes which do queries with databases. Write a UT using those mocks to produce desirable behavior and impose expectations on how the mocks are used in the system under test. 3. Non-deterministic code is not so non-deterministic. If it produces different results from call to call it means it takes some other input somewhere else, e.g. time. Stub the platform functions which return time and provide your own implementations so that you have control over the factors which make your code behave non-deterministically.
@DaevorTheDevoted
3 жыл бұрын
Thank you Ben, that was instructive.
@spiceEx
Жыл бұрын
where to find slides?
@mikeperry773
Жыл бұрын
Author::RetitleVideo(“How to use Google Test”); Thank you for helping with my homework!
@kuhluhOG
2 жыл бұрын
34:25 I need to disagree here because I had multiple cases where the public interface still seemed to do the correct thing, but the private functions didn't but in a way which made the error only detectable via other means quite a long time later. Also testing private function saved me way more time than you might think.
@pmcgee003
2 жыл бұрын
It seems like the only way that could happen would be - the return is incorrect, the test is incorrect, or the function is creating untested side effects. (?)
@perghosh8135
Жыл бұрын
Unit tests are good if you want to lock the code, make it hard to modify it. Do you want this? If not unit test are going to slow down the development process a lot.
@NKernytskyy
3 жыл бұрын
Like # 2^8.
@ivan4686
2 жыл бұрын
You put us too deep into your boring project with parsers and tokens
Пікірлер: 17