The talk gives a good idea about what you can do with gtest. The talk focused mostly on unit testing, but did not mention that good unit tests imho are independent from the environment. This means not reading any files or depending on the current time. It is also good to stress that gtest is a testing framework in which all types of tests (unit, integration, end2end) could be written. It is up to the developer to use the appropriate techniques fitting to the level of test that is written.
One test framework that is simple and easy to use is MS Test, and the test explorer built into Visual Studio. Extremely easy to use, well worth it if you develop on Windows.
Adding unit tests after writing the code is often very hard because your code will not be written to be testable. It’s also error prone because your test runner may succeed even though they don’t actually test anything. You might not even actually run your new testcase if you named it ”test” instead of ”Test”, but your test runner still reports success. Please try TDD and do it as early as possible in your project :)
I personally write a test while implementing the feature but not one per class but one per feature that can involve several new classes. Doing a test for each group of edge cases each class and method it seems like a waste of time
You get it! Tests should not map to functions or classes - tests verify requirements! This is the essence of BDD - given state X, when Y happens then expect an event or state Z. Simple as that! In some cases it is easier to test some requirement e2e and some in a unit test. Pick the scale that makes your work easier.
I don't think test-driven development works. Tried it, and it's just not a realistic way to develop software. Of course, there should be tests, including unit-tests, but writing the test before the feature doesn't work. Instead, iterate on the implementation until you're happy with the result and API. Then, before completing, add tests that verify the functionality of what you wrote. But, don't write tests to just call all the functions in the new API that you added; that's wasteful. Instead, the testing should focus on verifying the functionality, and if it means means only calling 15% of the functions you wrote, then so be it. The tests should verify both success and error conditions.
I'm always kind of ashamed to admit that this is what I do. I'm not against TDD, it does seem to work for many teams, but I have a hard time putting it into practice. It helps focus on the API but honestly, I feel I can reason about it without TDD as well.
I find the same. I would really like to find someone on a team that do do proper TDD 90% of the time and actually watch them implementing a realistic feature (that is not completely Greenfield code in a conference, which is easy to do via TDD). Clearly it does work for a lot of people, but whenever I have tried it it has just resulted in huge amounts of re-writing intermediate tests that didn't need to exist, and slowing down the rapid refactoring you go through when trying to find a way to make the code work, because each of those refactoring requires a double refactor as all the tests and mocks change as well. Maybe it is better for more senior engineers who can visualise more of the code that will need to be written up front. This is sort of what this chap is suggesting when talking about the feasibility of doing it for new projects, just at a different scale, very good pre-planning is needed to avoid those re-writes. Maybe if you can completely plan out where all the code has to go for the feature to work, you can do all the tests up front. Assuming you know the code base very well, and are reasonably experienced.
but that only works in an improvised way without clear requirement or something. TDD is great because you first think about what you want or not, then you or someone else does the implementations.
The talk gives a good idea about what you can do with gtest. The talk focused mostly on unit testing, but did not mention that good unit tests imho are independent from the environment. This means not reading any files or depending on the current time. It is also good to stress that gtest is a testing framework in which all types of tests (unit, integration, end2end) could be written. It is up to the developer to use the appropriate techniques fitting to the level of test that is written.
One test framework that is simple and easy to use is MS Test, and the test explorer built into Visual Studio. Extremely easy to use, well worth it if you develop on Windows.
Adding unit tests after writing the code is often very hard because your code will not be written to be testable. It’s also error prone because your test runner may succeed even though they don’t actually test anything. You might not even actually run your new testcase if you named it ”test” instead of ”Test”, but your test runner still reports success.
Please try TDD and do it as early as possible in your project :)
I personally write a test while implementing the feature but not one per class but one per feature that can involve several new classes. Doing a test for each group of edge cases each class and method it seems like a waste of time
You get it! Tests should not map to functions or classes - tests verify requirements! This is the essence of BDD - given state X, when Y happens then expect an event or state Z. Simple as that!
In some cases it is easier to test some requirement e2e and some in a unit test. Pick the scale that makes your work easier.
I'd like to see how to add tests to cmake and then to source control.
gtest is overcooked
Yep, test some good cases, some bad cases, and some edge cases.
I don't think test-driven development works. Tried it, and it's just not a realistic way to develop software. Of course, there should be tests, including unit-tests, but writing the test before the feature doesn't work. Instead, iterate on the implementation until you're happy with the result and API. Then, before completing, add tests that verify the functionality of what you wrote. But, don't write tests to just call all the functions in the new API that you added; that's wasteful. Instead, the testing should focus on verifying the functionality, and if it means means only calling 15% of the functions you wrote, then so be it. The tests should verify both success and error conditions.
I'm always kind of ashamed to admit that this is what I do. I'm not against TDD, it does seem to work for many teams, but I have a hard time putting it into practice. It helps focus on the API but honestly, I feel I can reason about it without TDD as well.
I find the same. I would really like to find someone on a team that do do proper TDD 90% of the time and actually watch them implementing a realistic feature (that is not completely Greenfield code in a conference, which is easy to do via TDD). Clearly it does work for a lot of people, but whenever I have tried it it has just resulted in huge amounts of re-writing intermediate tests that didn't need to exist, and slowing down the rapid refactoring you go through when trying to find a way to make the code work, because each of those refactoring requires a double refactor as all the tests and mocks change as well.
Maybe it is better for more senior engineers who can visualise more of the code that will need to be written up front. This is sort of what this chap is suggesting when talking about the feasibility of doing it for new projects, just at a different scale, very good pre-planning is needed to avoid those re-writes. Maybe if you can completely plan out where all the code has to go for the feature to work, you can do all the tests up front. Assuming you know the code base very well, and are reasonably experienced.
but that only works in an improvised way without clear requirement or something.
TDD is great because you first think about what you want or not, then you or someone else does the implementations.
Not very liked it