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.
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...
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.
31:00 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"
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
If algorithms + data structures = programs and also structure + interpretation = programs then algorithms + data structures = structure + interpretation . HmmMM!
"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.
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.
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.
@@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 ?
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.
The part of the talk on test naming was very instructive, thanks
This is the most concise version of this talk, and it contains lessons that may take multiple viewings to sink in. I loved it.
Kevlin took just a simple idea that it code is your documentation, and crafted just a spectacular speech! I enjoyed it
awesome talk, really wakes me up
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.
are all the talks this funny!! oh boy I would love to meet this person. or "Should" meet the person! :D
As a TAE, I like this very much ❤️
Thank you! Very interesting.
4 wasn't a leap year because they were not tracking leap years until 45 and then it was only the four year interval.
Parametrization in pytest is great for good descriptive test names.
I love using that
"You've always been breathing air"
"I knew that..."
"You've always been breathing argon, neon, methane, krypton"
"????"
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...
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.
I know it's random, but I love the t-shirt :)
What, you have a Silver Bullet in another talk, then why am I listening to this one then?!
31:00 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"
34:00 oh never mind, you explain that :D
The venn diagram looks really inspiring. Would someone just elaborate a bit more about the simple cases?
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
If algorithms + data structures = programs and also structure + interpretation = programs then algorithms + data structures = structure + interpretation . HmmMM!
Thereso
algorighms = structure + interpretation - data structures
data structures = structure + interpretation - algorithms
structure = algorithms + data structures - interpretation
interpretation = algorithms + data structures - structure
You have to paint the turtles all the way down.
Class or No Class that is the question...
what happened
The key takeaway from this video is, "You must write the Test Cases to utilize 100% of the method with all the possible cases".
"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.
I am sorry, but I fail to see the value of Unit testing ! It was invented to support the stupid dynamic languages like Python
there is mostly no value in unit testing
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.
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.
@@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 ?
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.