Open rdebeasi opened 5 years ago
@rdebeasi This is an interesting conversation to have. I definitely understand what you are saying. That said, I feel like emphasizing TDD and Test First is the right thing to focus on, and if we have to allow for a more relaxed intermediate state it would be OK. The reason for my opinion is that we should be encouraging "Best Practices" and realize that not everyone can achieve best practices out of the gate.
I’m brand new to Red Hat and Labs. Last week I took the DO500 course, knowing that I will be teaching the course in the near future. I absolutely agree that the instructional focus should be on understanding the value of automation and test-first practices, such as TDD and BDD. It struck me in the class that the TDD diagram was rather complex and I would like to suggest that we simplify it with something I’ve used in the past. Like this 3 step (red, green, refactor) one: https://www.allaboutcircuits.com/technical-articles/how-test-driven-development-can-help-you-write-better-unit-tests/
That way instead of going through all the loops of the current diagram we can focus on the essential aspects to test first - Automation and literally writing the test before the implementation.
Hi eric - interesting you suggest this and I completely agree. The loop the GLS team have added is way more complex than necessary. I have swapped to using the simple RED / GREEN / REFACTOR method myself too when delivering the content. The slides should be updated to include this diagram.
As for the exercise, we now have an ability to run either the Techie exercise after tests in the pipeline OR the Lego based version. If someone wanted to create a Lego BDD one that too would be cool
Hi @springdo, I realized now that further in the slide deck is the simple RED/GREEN/REFACTOR slide with three animations, one for each state. I'd like to see us do the change - 1. Copy the simple slide with the three animations in place of the complex slide; and 2. Keep the simple slide in its original place, removing the animations. (Kind of a quick reminder.) What else needs to happen before we (I) can make such a change?
In the slides and technical exercises, we focus on test-driven development. While that's definitely a great way of doing things, I wonder if we're missing some stops on the journey from "no tests at all" to TDD.
In Labs residencies, we don't start every feature by writing a test or aim for 100% coverage. Instead, we encourage teams to begin writing tests if they aren't already, and we focus on writing meaningful tests using behavior-driven development (BDD).
Most teams that we've worked with are psyched about automated testing, but they typically are not ready to jump into full TDD just yet. From what I've seen in DO500/enablement classes, most participants are in a similar place.
Let's consider emphasizing automated testing and/or BDD over TDD so that we can a.) meet people where they're at and b.) be super transparent about what we accomplish in a residency.