Test Driven C++ - Phil Nash - CppCon 2020
HTML-код
- Опубликовано: 13 сен 2024
- cppcon.org/
github.com/Cpp...
---
We know that testing is important, but writing tests is hard and takes time - and can be demotivating when you want to hack out features.
But what if we flipped the whole thing around? It turns out that by writing tests first the dynamic changes in unexpected ways. Testing becomes easier. Adding features becomes easier. The dopamine hit you get from seeing something work becomes more frequent. Time lost to bugs and regressions virtually disappears. You start to get invited to bigger and better parties!
Ok, one of those statements is not guaranteed - but the rest are! If you've never tried TDD (perhaps you have heard of it but been skeptical), or maybe had a bad experience in the past, this talk will give you a sound intro to how it work, how you can get started, and what you can expect to achieve.
---
Phil Nash
Developer Advocate, JetBrains
Developer Advocate at JetBrains, author of Catch/Catch2, co-host of cpp.chat, host of C++ London, chair and organiser of C++ on Sea.
---
Streamed & Edited by Digital Medium Ltd - events.digital-medium.co.uk
events@digital-medium.co.uk
*-----*
Register Now For CppCon 2022: cppcon.org/reg...
*-----*
"The dopamine hit you get from seeing something work becomes more frequent. "
OK OK, you got me
I think that the design stage before writing the first test is totally dependent on the project. Sometimes you already have an idea of what to write and sometimes it is just too complex, to the point that you have to do write a lot of extra research code before even beginning to creating your production solutions. I think one of the keys to efficiency is to actually distinguish those modes and alternate between them. This goes against TDD, which is a more strict process. I do AI programming for a living, so I may have more research tasks
than some other people, but I think that my point is universal.
This is the main point lacking from this presentation. Phil didn't even properly explain what are the requirements of the snakes and ladders program (interactive program? simulation? other?). The presentation assumes that the Board data structure is what we should be writing. One consequence is that I cannot tell what would I be writing in his place, for example if I would actually attacking the problem from an entirely different angle.
This is not to say that TDD is not useful (I like it), it's just not really *placed* into the development process by this presentation.
Sounds like a valid point to me: the first requirement of testing is a great description of the problem, and games are usually a lot of sub problems all going on at the same time.
@@bakedbeings I think it was a pretty terrible example of TDD. There was no description at the outset of what the code module was intended to do and before creating any tests he started implementing data structures!
True, but also when the developers get more experienced I'm quite sure they can lean it towards more of TDD by writing tests first then development.
That's not the TDD that is problem, it's the people that have distorted to the point of ridiculousness an idea that you need to write code and design apps so that it would be convenient to cover it with tests AFTER it's written.
I think writing a passing test _can_ be part of TDD: When the test assures a behaviour you know you will have to touch will not get broken by your implementation (but you assume it might or will be). Although I guess whether you consider that part of it or not is pretty philosophical.
I would enjoy if the instructor when coding, wrote the interface first (step by step when writing new tests), and no code until the interface required a change and other implementation. That would make more sense and he would show how he then follows the TDD cycle he presented at start instead of doing it against the rules he presented, in reverse order.
Yeah, a stub that passes, then functionality that breaks it, then passes, then refactor.
@Kuberlog the CyberRanging Hacker its irrelevant, totally superfluous step
Great video :) Thanks for the code tutorial section, following along with it helped loads.
Great to hear! Thank you for your comment.
Thumbs up for thinking about colourblindness after referring to a diagram with red and green boxes.
I'm glad it was noticed. I've talked about the RGR cycle a lot before, and usually forget to make mention - I'm trying to be more mindful!
We tried Automated testing with mocks and very quickly came to the conclusion that the mocks were getting in the way as we were spending far more time rewriting mocks when minor changes were required to the component being mocked. In particular modifying the database schema in almost any way would cause an extraordinary number of mocks to have to change. We gave up on DB mocks and just used a DB that started in a known state.
Also the tests were taking nearly a day to run.
I know we were doing something wrong, but I'm still not certain what. We were bolting automated tests onto a large legacy system.
Cuando se hace TDD no tiene mucho sentido incluir las bases de datos (ni los interfaces gráficos) en los tests. Los tests siempre deben ser rápidos.
Why did you actually write the struct Portal and the portals map before writing a test? As you initially told that we should write a test before writing *any* code.... And for the initial board test and class those portals don't seem to be needed at all (not even for the first versions of the landOn method), they only seem to be needed in somewhat later stage of development... ?
Good question. I didn't really explain it this time. Normally, when I use this example, I say that this is very declarative code that captures the essential model. Not that it shouldn't have tests - but the tests are about bringing the model together with the interface. I was also quite pushed for time - still ended up running out!
Thanks for the explanation of TDD!
TDD does NOT work.
thank you , great talk
Glad you liked it!
C#.Net and C++/CLI: Can it be effectively used with Catch2?
Where was Catch.cpp ????
Cant wait!!
What presentation software did he use for this talk?
KeyNote
Excellent example
At the end of a sprint, you'll have 100% of the tests and 40% of the task completed. "Management" is not smart enough to understand that more tests = more time. They are not free.
Very good example of Buddha's middle path. Real purists would have forced the portals- map to be also Test-Driven. Just data. Like you won't force a Db-Connection-String by a test, although it might be used in an integration test...
Catch2 is amazing
your laptop fan is quiet, looks like you bought a new macbook
The code written is way too bloated: a simple uint32_t tile[101]; is enough to do everything you want.
tile[i] == i => not a special case
tile[i] > i => ladder
tile[i] < i => snake
tile[i] == 100 => WIN
No need for Portal, no need for Action, no need for a board, no need for a map.
Imho, TDD did not help you write better code.
There are certainly different approaches - and some of the choices I made were at least partially to give me an opportunity to talk through them. That said, I'm not sure I agree that an array based approach is "simpler" at a conceptual level.
But what if your board size is more then 1'000'000 squares and you have only few snakes and ladders?
@@nikitavasilev6904 Different problems, different solutions.
In this case the board is known and defined very precisely, so there is no need to consider different board sizes or different ladder/snake distributions.
@@philnash3269
I have put a small C file to better illustrate: github.com/Julien-goupy/yt_comment/blob/master/code.c
I used the knowledge of the game to make design decisions, used the simpliest code possible and used outputs to detail the intended logic making it very easy to understand, to test and debug.
I suspect that using TDD increase the complexity of one's programs as one lose the big picture and what are the underlying hypothesis/knowledge of the problem.
Does anyone know what IDE he was using?
i belive its clion it could vscode but im pretty sure its clion with the left hand menus minimised
CLion.
He mentions the name several times.
CLion (from JetBrains) of course :-)
Clion from JetBrains
CLion. He said in the video.
This is the most ridiculous and nonsensical approach i've seen. It's like hitting your hand with a hammer before hitting the nail to ensure it hurts. What world do you live in? The world where you walk into your neighbor's dog house before you get into yours just to be sure? It looks like somehow you've come to conclusion that you feel smarter thinking backwards. As for normal people it's more common way to thing with logical sentences from start to finish and put the restricting roadblocks after you've build a road not before.
I just don't get how anyone could have taken the paradigm of the software development that has embraced the crucial necessity of the test coverage in mind projecting onto the application/code design and turned it into something where low quality tests are required to be written before code. And all that is done in stuttering chunks. What a waste of time and intellectual resources!
take a step back - the quoted part happens only when the paradigm is followed mindlesssly word to word. the way i was introduced in perl was that:
* you first design the interface of say your API or CLI. (edit: so yeah, 54:34)
* then you write proper tests - the interactions you think will happen and corresponding to which your application should perform expectedly.
* then you write the code to make those tests pass.
so yeah, it goes back to 3:45 behaviour or design driven development
this vid only shows those be broken to absolutely small steps - which gave you impression of "low q tests" - but you can leave that and operate on whatever level and block size you are comfortable to work on upon.
the "demo" part shown here may not be greatest thing - but that is cause
* good and small samples are hard to come up with, and
* live demos are sometimes difficult.
> _"where low quality tests are required to be written before code"_