We just shipped core framework v3 2.0.2 and Visual Studio adapter 3.1.0.
Check the release notes for new features and bugs fixed.
Note: The Visual Studio adapter has moved up to .NET 8 (from .NET 6).
https://xunit.net/releases/v3/2.0.2
https://xunit.net/releases/visualstudio/3.1.0
Quelques bonnes pratiques pour tester votre application Node.js.
🔗 https://github.com/goldbergyoni/nodejs-testing-best-practices#readme
We have a prototype of the API documentation online: https://api.xunit.net/
We're not sure if it will live on a separate URL forever, but until the main site is rebuilt with DocFX, this is how it has to be for now.
Feedback welcome!
We just shipped core framework v3 2.0.1 and source analyzers 1.21.0.
Check the release notes for new features and bugs fixed.
https://xunit.net/releases/v3/2.0.1
https://xunit.net/releases/analyzers/1.21.0
Nach Null setzen der Klassenvariablen in der tearDown() die die Referenzen hatten gehen die Zähler auch wieder runter und der scheiß fliegt mir nicht mehr um die Ohren 🙌🏼
Damit bleiben natürlich auch diese Instanzen referenziert und werden nicht aufgeräumt.
Mit wachsender Anzahl Testklassen, werdens also auch immer mehr Referenzen die unnötig weiter Platz belegen und 🤯
Hab die Theorie dann eben mal überprüft, indem ich in Kon-/Destruktor der instanziierten Klassen einen Zähler gepackt hab.
Und recht gehabt.
Ich hab mittlerweile so viele Unittests in dieser Suite drin, der VM HeapSpace fliegt mir um die Ohren 😶🌫️
Heute morgen also mal Speicheroptimierung in den Unittests betrieben :blobcatverified:
Was war passiert?
Naja, ich hab in der setUp() 9 Objekte instanziiert und in Klassenvariablen der Testklasse abgelegt.
Well, am Ende des Tests, hält die Testumgebung die Referenz auf alle Testklassen bis sie mit allem fertig ist, für final Reporting. 👀
https://github.com/SwissLife-OSS/snapshooter - SnapShooter is a #dotNET #UnitTest snapshot tool (think Jest snapshots). Run it once, save the result, and every other test run compares to that result. For when you're asserting something big like a rendered email template.
https://jwtguard.net/ - #JWT Guard is a cool #dotNET #UnitTest suite to verify your #ASPnet app's #OAuth2 implementation is secure. I had fun poking at it and working with https://www.linkedin.com/in/wcabus/ to look at .NET User JWTs with it. Turns out I had misunderstood the purpose.
Do you know a #language that allows you to mock a public method of the currently tested class in #unittest ?
I mean in #cpp ... I'm testing "method1" that calls "method2" (both are public), and then I must test both of them in the same unittest? It looks ugly. It may be nice to #mock this "method2", even if it's part of the class under test. Right? 🤔
Holy crap! I just noticed we're up to 130 unit test suites in @pidgin 3 now! Compare that to the 7 suites we have in Pidgin 2!
This is what we've been talking about when we've been saying that we're making the code easier to maintain. The code has been reworked so that we can actually unit test way more of it and we will continue to add more tests as we move forward!
Simplified HTTP Response Mocking in Laravel Tests - Laravel News https://links.shikiryu.com/shaare/zV30ew
#laravel #test #unittest
{testthat} is great for automatic testing. Here are some tricks for the heavy user: https://blog.r-hub.io/2020/11/18/testthat-utility-belt/ #rstats #testing #unittest #testthat
If you have many assertions, you can also use the SoftAssertions to test all the assertions and give all the results at once.
Read more 👉 https://lttr.ai/ATQTo
#test #unitest #unitTest #testing #AssertJ #assertions #code #developer
More thoughts about test parallelism as it involves the starting/finished message pairs for test collections, test classes, and test methods.
If you're a runner author, do you use these messages? Can we just remove them?
Provide thoughts here: https://github.com/xunit/xunit/discussions/3164#discussioncomment-12217024
A good first step.
These tests (and xunit.v3.assert.aot) are compiled with <PublishAot>true</PublishAot>, but still being run normally (not via a published executable). It's hard for me to know how many *more* tests might fail after publishing, but that's quite a ways off.
Thinking about what an AOT version of @xunit would look like. I spent some time talking to @agocke last year about it so I have some thoughts.
It almost surely end up being a completely separate code base/package. No mixing and matching, because the internal design would be very different.
Top three things I think:
- .NET 8+ only (no .NET Framework)
- C# only (no F# or VB)
- No extensibility points (you get our Fact and Theory, you get our pipeline).
1/
