The part of the talk on test naming was very instructive, thanks
@JeremyAndersonBoise2 жыл бұрын
This is the most concise version of this talk, and it contains lessons that may take multiple viewings to sink in. I loved it.
@hanif72muhammad3 ай бұрын
awesome talk, really wakes me up
@StormB872 жыл бұрын
Kevlin took just a simple idea that it code is your documentation, and crafted just a spectacular speech! I enjoyed it
@CJE-Software2 жыл бұрын
Love This! This man is brilliant 👏 thank you for offering this to the community for free. OG programmers take scope and scale to a whole different level, it's enlightening.
@sixbutton9Ай бұрын
4 wasn't a leap year because they were not tracking leap years until 45 and then it was only the four year interval.
@vibhanshubiswas8729 Жыл бұрын
are all the talks this funny!! oh boy I would love to meet this person. or "Should" meet the person! :D
@peretch2 жыл бұрын
Thank you! Very interesting.
@radekBednarik2 жыл бұрын
As a TAE, I like this very much ❤️
@RoamingAdhocrat2 жыл бұрын
for some reason I'd believed it was a hard requirement to use `test_` at the start of test names, or something you could painstakingly configure around. But no - just needs to be in a _module_ named "test_*.py" or "*_test.py" for pytest , and xUnit uses the `[Test]` attribute obviously...
@STFU665 Жыл бұрын
As for the leap year thing. This can be solved very easily in the lowest set of chars, so to speak binary. You just need a start binary indicator and then resolve where the next one is + 100 (You only have to check if the starting point is a binary 100 in the first 3 places, if not, the next after adding binary 100 will never be a leap year). As an example we have year binary 0 then the next binary leap would be 100. If we got for example year 2000 as binary, which gives us 11111010000, by binary addition we get 11111010100. This even works for all the years before 1970 (see Microsoft SQL Server limitatons on dates). I actually don't know who began all the calculations in decimal systems for these types... Tests are nevertheless very usefull, you can easily find flaws or certain conventions of a language by tests, to check if they work as you expected or a update on the compiler changed your functions in the asserted results. Update: Just checked my statement again: it's a leap year if in binary the 3rd bit from the last significant bit is either 0 or 1 and the last 2 lower significant bits are not 1.
@adrianperez86952 жыл бұрын
Parametrization in pytest is great for good descriptive test names.
@nicholaslogan5185 Жыл бұрын
I love using that
@RoamingAdhocrat2 жыл бұрын
<a href="#" class="seekto" data-time="1860">31:00</a> Is the year 4 CE a leap year, though? What does it mean to say "there was a Feb 29th in 4 CE even though no-one was using that calendar for centuries after"
@RoamingAdhocrat2 жыл бұрын
34:00 oh never mind, you explain that :D
@Yupppi11 ай бұрын
"You've always been breathing air" "I knew that..." "You've always been breathing argon, neon, methane, krypton" "????"
@licg99992 жыл бұрын
The venn diagram looks really inspiring. Would someone just elaborate a bit more about the simple cases?
@bkkothari2255 Жыл бұрын
simple cases meaning define the area / range you want to cover to test boundary cases meaning edge case extreme limit/lower limit of your range common cases meaning generally you have conditional statements results which should be passed error cases meaning your test case condition should produce the errors with given wrong inputs Hope this helps. Let me know if you have a different understanding
@w4750n2 жыл бұрын
I know it's random, but I love the t-shirt :)
@brynyard Жыл бұрын
What, you have a Silver Bullet in another talk, then why am I listening to this one then?!
@noraosmena4997 Жыл бұрын
what happened
@BryonLape Жыл бұрын
You have to paint the turtles all the way down.
@logiciananimal2 жыл бұрын
If algorithms + data structures = programs and also structure + interpretation = programs then algorithms + data structures = structure + interpretation . HmmMM!
@1Cry19872 жыл бұрын
Thereso algorighms = structure + interpretation - data structures data structures = structure + interpretation - algorithms structure = algorithms + data structures - interpretation interpretation = algorithms + data structures - structure
@gr8john6 Жыл бұрын
Class or No Class that is the question...
@pollathajeeva23 Жыл бұрын
The key takeaway from this video is, "You must write the Test Cases to utilize 100% of the method with all the possible cases".
@BuffNerdInCa Жыл бұрын
"We only have 90 minutes. " Unfortunately, those are spent more trying to entertain than inform. Much of this could be paired down into a far more concise presentation.
@sergebureau22252 жыл бұрын
I am sorry, but I fail to see the value of Unit testing ! It was invented to support the stupid dynamic languages like Python
@redhotbits2 жыл бұрын
there is mostly no value in unit testing
@pepijnkrijnsen42 жыл бұрын
The idea of unit tests (if not necessarily test-first) has been around since the '70s. Kent Beck wrote the SUnit framework for unit testing Smalltalk code in 1989, the year Python 1 was released. JUnit and other xUnit frameworks were developed and widely used in the '90s before Python 2 was released in 2000. Claiming that unit testing was invented to support dynamic languages like Python is nonsense.
@KristoffelPirard2 жыл бұрын
Not a very constructive way to formulate that you don't see value in dynamically typed languages. Just use the right tool for the job. If that's Haskell for you, great - you get lots of bugs detected for you by the compiler. If it's Lua, great: great flexibility with a small footprint - use automatic testing. If it's C: great, use a team of testers to find your bugs. The list goes on. Choose wisely, away with the disdain.
@sergebureau22252 жыл бұрын
@@KristoffelPirard I prefer a few tools for all the jobs. So many languages are to be destroyed, they give bad habits and are bug generators. That is what you recommend ?
@JohnnyAdroit2 жыл бұрын
What does the language have to do with the value of testing? Code that compiles cleanly can still do the wrong thing. bool is_leap_year(int year) { return year % 4 == 0; } is type-safe, cleanly compiles, and runs without error, and yet it does the wrong thing. Without specifically testing the behavior of the code, one cannot know whether the implementation of an algorithm is correct.Testing happens in the problem domain, not the source code.