Boas práticas de programação fazem bem para as pesquisas quantitativas... e, por acaso, para a prática clínica:
https://blog.leonardof.med.br/2025/ckd-epi-sbn.html
Fui usar "teste de unidade" ("unit testing", em inglês) no código de análise estatística que eu estava escrevendo, e descobri que uma calculadora online da Sociedade Brasileira de Nefrologia estava errada.
Automated tests in my survival mode quest plugin :D
Now I just have to write more of em
https://github.com/sammypanda/MCJE-PlayerQuests-Plugin/pull/169
@encthenet Oh darn, yeah that's mildly annoying of numpy. But there's still the regular temporary file handling. Who knows, working with in-memory fake files may not even make a significant difference if you could do it, compared to temporary files if they live on, say, a shared memory partition.
That won't work. It says so in the docs:
> pyfakefs will not work with Python libraries that use C libraries to access the file system.
Which is what numpy is doing.
@encthenet @rachelplusplus Dunno if you've considered this, or would consider it, but pytest has a plugin, pytest-fakefs (https://github.com/pytest-dev/pyfakefs), that implements an in-memory filesystem complete with file objects that you can use to test file handling code without having to put things on disk. IMO the plugin ecosystem for handling things like this is one of pytest's biggest advantages over unittest.
Or if you prefer, pytest also has built-in functionality that makes working with temporary files pretty easy.
A couple weeks ago, I gave a talk at @omt_conf on What's New in Testing. That talk was recorded, but while I wait for it to be edited and published, I published an edited (and updated!) version of my speaker notes from that talk.
There's a lot new in testing since last year. I'm still surprised there wasn't a WWDC video about all the new things you can do.
https://rachelbrindle.com/2025/06/26/whats-new-in-testing-swift-6-2/
@nedbat I'm used to JUnit's assertEquals(expected, butgot) and it prints
Expected <<<x>>> but got <<<b>>>
Which is slightly better when you have long chunks of output (HTML and XML), butgot will be at the end instead of buried a page or two up. For short answers it doesn't matter.
#unitTesting #extremeProgramming #soExtreme!
My talk at OneMoreThing 2024 on #UnitTesting #SwiftUI and #SwiftConcurrency was recorded, but has yet to be edited and uploaded.
Last night, I published an edited form of my speaker notes from that talk to my blog.
https://blog.rachelbrindle.com/2025/06/12/testing-swiftui-and-swiftconcurrency/
Video 3 is out. You don't want the app launching (and mucking with networking, persistence, and analytics) during tests, do you? #Xcode #UnitTesting #SwiftUI https://www.youtube.com/watch?v=SSM2_a0_yIk
Check out video 2 in my new series #Xcode #UnitTesting https://youtu.be/r21JXSQtvgs
Sometimes you gotta sherlock yourself. I think that Swift Testing should have something akin to Nimble's Polling Expectations.
https://forums.swift.org/t/pitch-polling-expectations/79866
Also, wow, macros are hard. I am so glad I don't have to write them on a day-to-day basis.
Automate your unit tests in #DotNet like a pro!
Learn how I use GitHub #Copilot Agents to create, run, and iterate on tests until everything compiles and passes!
Smart prompts
Save time and focus on what matters
#VSCode #UnitTesting #DeveloperExperience
wp.me/p29SK-YK
falsify
A few days ago, Edsko de Vries of Well-Typed published an in-depth article on property-based software testing, with a focus on the concept of “shrinking.”
In brief, property-based testing is sort-of like fuzz testing but for algorithms and protocols. Like fuzz testing, random test cases are procedurally generated, but unlike fuzz testing, the test cases are carefully designed to verify whether a software implementation of an algorithm satisfies a specific property of that algorithm, such as:
n*log(n)
number of iterations for input dataset of size n
““the sequence of log messages is guaranteed to obey this rules of this particular finite-state automata: (connect | fail) -> (send X | fail) -> (receive Y | receive Z | fail) -> success .”
Shrinking is the process of simplifying a failed test case. If you have found some input that makes your function return a value when it should have thrown an exception, or produce a result that does not satisfy some predicate, then that input is a “counterexample” to your assertion about the properties of that function. And you may want to be able to “shrink” that counterexample input to see if you can cause the function to behave incorrectly again but with a simpler input. The “QuickCheck“ library provides a variety of useful tools to let you define property tests with shrinking.
Defining unit tests with such incredible rigor takes quite a lot of time and effort, so you would probably do not want to use property-based testing for your ordinary, every-day software engineering. If you are, for example, being scrutinized by the US Department of Government of Efficiency, you would likely be fired if you were to take so much time to write such high-quality software with such a strong guarantee of correctness.
But if you are, for example, designing a communication protocol that will be used in critical infrastructure for the next 10 or 20 years and you want to make sure the reference implementation of your protocol is without contradictions, or if you are implementing an algorithm where the mathematical properties of the algorithm fall within some proven parameters (e.g. computational complexity), property-based testing can give you a much higher degree of confidence in the correctness of your algorithm or protocol specification.
Neat! #Duende is sponsoring #dotnet project Shouldy for the next year for $3,000. #unittesting #xunit #nunit #mstest
https://blog.duendesoftware.com/posts/20250415-shouldly-assertion-framework/
3 Reasons .NET Developers Still Struggle with Unit Testing (And How to Fix It).
https://www.typemock.com/why-dotnet-unit-testing-feels-hard/
3 Reasons .NET Developers Still Struggle with Unit Testing (And How to Fix It).
buff.ly/Cjn1j6m
#dotnet #csharp #unittesting
3 Reasons .NET Developers Stil...