Testing in .NET is About to Change
Вставка
- Опубліковано 19 вер 2024
- Until the 30th of September get 30% off any course on Dometrain with code BTS30: dometrain.com/...
Subscribe to my weekly newsletter: nickchapsas.com
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video I will introduce you to a brand new testing library in .NET called TUnit. TUnit aims to be the new way of doing testing in .NET and I am very excited about its future.
Give TUnit a star on GitHub: github.com/tho...
Workshops: bit.ly/nickwor...
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elf...
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet #codecop
Personally I prefer PUnit.
Testing in Production :3
🤣🤣🤣
We have shitty tests that randomly fail and depend on one another. Now we got a perfect framework to hide it and not having to fix these damn tests. YAY!!!
Now I can over-engineer my tests easier than ever! ;)
I use GUnit
TestsSucksUnit =)
Before assembly, what a fantastic way to hide weird behaviour in a large test suite.
Because doing things before tests is weird. And how is it going to hide it if the code that runs is annotated with Before(Assembly)?
@@cyril113
Doing things before tests is fine. Doing things before EVERY test invites problems through dependencies and bloat, because a lot of people do not really understand what *should* be running before all tests. Then someone starts doing it, and some other person needs another thing for their tests and extends what is already there, and then it slowly, over weeks and months, grows into a tangled mess that is hard to maintain.
Honestly, from my experience, a lot of people already struggle to figure out how to use a [Before(Test)] properly, let alone [Before(Class)]. This is just one step further up.
"And how is it going to hide it if the code that runs is annotated with Before(Assembly)?"
Because the code with this annotation is very likely not declared in the same class file that I am working on when my test fails. Yes, I can go and look for it, or maybe the test output log even tells me about it (I hope it does), but if I don't know it is there, I risk to end up in a scenario where my test fails with seemingly unexplainable behavior.
This doesn't mean you should never have a [Before(Assembly)], it just means you have to be very careful and understand what you are doing.
Not true for acceptance tests where you’re spinning up a bit suite of tests.
We need *test* frameworks not just *unit* test frameworks (we use them for more than just unit tests)
I'm happy with NUnit
Yeah, I expected something really flashy. But aside from using the new test runner, it mostly feels like NUnit. Maybe it has a few more options for "Before", but otherwise, it feels the same.
xunit is streets a head of nunit
2:15 I love how nick chooses "random" numbers
If only the test ran for 260 seconds too
Liked for "Assert DOT THAT DOT IS DOT " -Dance
Really, most projects just need some library that can assert things and some framework that can run those assertions. I've never met a real-life scenario where unit-tests related reflection would be the bottleneck why unit tests run slowly.
Also these days you might want to use a library that LLMs know about, so that you could autogenerate test cases sometimes. But that's about it, it's not that complicated.
So much hate in these comments. If you’ve never ran into the limitations of xUnit then you wouldn’t realize the benefits. A lot of people override the standard xUnit framework because parallelization in xUnit is bad and not as configurable as it should be. Once you do that it’s extremely difficult to use spec flow on top of it or some other framework
This is excellent to see its source generated. It’s the way to go
This is pretty cool. If I'm writing unit tests, its true I might not see the value with this framework if all my tests are perfectly isolated. But for integration tests/UI tests, i can finally not have it run in one giant method and finally have test order control! This is really useful for different types of testing.
Thanks for intreducing a new tool to our toolbelt, now we know it exists we can decide if and when it might solve us a problem. Cool library thanks.
What about support for build pipelines? Are there any pros and cons there?
There is no AI in it? Pfffff, what a waste. [ɯsɐɔɹɐs].
AIUnit next
reminds me of the spec flow library
Thanks for the info. As always, refactor all unit tests and use it in production even if it's in preview library, you will thank me later.
Hmmm maybe overtime it will show more advantages over other testing frameworks, but NUnit/XUnit are both decent, well supported, and feature rich, so it does make it more difficult to switch at the moment. But that being said, it's new and no doubt will get better, so who knows 😊
I see no value bar its a bit faster. change for the sake of change. in the end you should be running the test your working for then a final full run before you push. after that the pipeline does the testing and really who cares on the speed of that since if its spec'd correctly it will be no issue. If my app is so large and complex that it is way to slow on testing. either your writing tests wrong or your at the point to rearchitecture and or move to go or something that better suits larger projects.
Looks exciting, but I was hoping to see property-based unit testing here. Patiently waiting for the first library that makes it really accessible for .NET.
I see the same problem with TUnit and NUnit, which is not present with XUnit, which is thats it's a lot easier to use and code tests quickly with resharper. With just base resharper if I decide some line in my code needs to be setup before the test just a quick keyboard shortcut and its automatically moved to the constructor. This make writing tests a lot faster and easier since you don't need to write boilerplate code by hand.
Also XUnit assert syntax is a lot better in my opinion
You can do the same thing in TUnit
Oh hell yes! I likey!!
Yeah, this should get some funding sent it's way for sure.
I wish .Net had testing builtin like Rust and actually support the same way of having a testing module in the same file that is only compiled when running tests.
100k, you deserve it !
Man.. just used NUnit 😢
Keep using it. TUnit will not exceed NUnit in a long time, and any experience you gain will be usable in TUnit just as much.
Keep using it, TUnit is not ready yet
It is ok to not be using every new thing all the time.
What is the point of DependsOnI(OtherTest) ? This is violation of FIRST principles in unit testing. Unit tests shouldn't depend on one another.
Like I said, it’s not for unit testing
Nice, it's closer to NUnit rather than XUnit. I like they put `Before(Test)` which is feature I miss from NUnit but not in XUnit. But, I have to await for assertion? Ok, time to get used to.
Nick, would you consider making a video about required CET in .NET 9 and the 10-100% method calling performance regressions that come with it on any CPU that isn't a modern intel processor?
Wait that’s a thing??
@@nickchapsas Yes, and it's causing major performance regressions for CPUs that do not have specialized hardware for CET. It also causes issues when interoping with other runtimes that don't support it, such as Java (the specific JVM is not named).
UA-cam keeps removing my comments, probably because of my sources. You can check 107651 and 103654 in the dotnet runtime and 36619 in perf-autofiling-issues.
Source generated test library 👀
Nah, this is just a conspiracy to cover the entire alphabet
I wished for G Unit but I wasn’t lucky this time
I think it's better to add these futures to XUnit or NUnit instead of recreating a library or maybe a package for XUnit or NUnit to add these futures because most of us don't like to go for a new library
Was it necessary to mention how handsome is he!! 😅😅.
Great library will give it a try
Add(6,9) nice 🤣
Even if i wanted to use it, Projects will still just have N/X Unit 😂
can we stop add more ways to write tests. Focus on doing less and less tests. Let AI write tests for us.
The best way to write integration tests is not use C# to write them. I simply run my C# app and the environment in docker and send requests from jest tests in js. Tests are very short and run concurrently. Jest looks miles better than this.
Usually you want to test the final effects of the execution, such as if the data is correctly stored in the database. I'm not sure if this is easy with Jest but with standard integration tests you just query the same DB that was used for testing.
There is no way Javascript ever could ever look better than c#.
You can do queries in js of course but you don’t necessarily have to query the database manually. For example if you test POST endpoint you can check the result via GET endpoint
Why do I feel like I've used something like this in Java, christ I hate Java.
First!
Offers basically nothing interesting over xUnit/NUnit. I don't know what I'm supposed to be excited about here.
If you can’t see it then it’s not for you
Same here. I can't see anything that I can't do in NUnit.