Test Driven C++ - Phil Nash - CppCon 2020

Cant wait!!

Catch2 is amazing

Does anyone know what IDE he was using?

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.

Excellent example

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.

Thumbs up for thinking about colourblindness after referring to a diagram with red and green boxes.

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.

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... ?

Thanks for the explanation of TDD!

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.

your laptop fan is quiet, looks like you bought a new macbook

"The dopamine hit you get from seeing something work becomes more frequent. "

OK OK, you got me

thank you , great talk

Great video :) Thanks for the code tutorial section, following along with it helped loads.

C#.Net and C++/CLI: Can it be effectively used with Catch2?

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...

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.

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!

Where was Catch.cpp ????

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.