WFN
WFN copied to clipboard
wokhan
Migrate the test projects: Common.Tests, Console.Tests and Notifier.Tests
Hi @wokhan, you said you want to migrate to another testing framework - which one is your preference?
Do you know in project Common.Tests > properties it shows:
... and when I edit Common.Tests.csproj it shows:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop"> <PropertyGroup> <TargetFramework>netcoreapp3.1</TargetFramework> <AssemblyName>WFN</AssemblyName> <RootNamespace>Wokhan.WindowsFirewallNotifier.Console.Tests</RootNamespace> <Description>Windows Firewall Notifier - Common Tests</Description> <Product>Windows Firewall Notifier</Product> <Copyright>2011-2020 Wokhan (https://github.com/wokhansoft/WFN)</Copyright> <Authors>Wokhan Solutions</Authors> <OutputPath>..\bin\$(ConfigurationName)</OutputPath> </PropertyGroup>
No idea where the properties are picked up from :(
Well it was thatt line (when I uncomment it):
<!-- <Import Project="$(VSToolsPath)\TeamTest\Microsoft.TestTools.targets" Condition="Exists('$(VSToolsPath)\TeamTest\Microsoft.TestTools.targets')" /> <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> -->
But without the tests are not detected 😦
I'm using xunit, which basically requires three packages: xunit, xunit.runner.visualstudio and Microsoft.net.test.sdk. Xunit comes with some differences from usual testing, it's about Facts and Theories (basically a test, and a variation that takes multiple data to test against).
Even Microsoft is using it in fact, at least for some of their .net core projects, hence the choice (amongst other reasons).
Ok if Xunit is the choice (and easy to handle for our purpose) we should do the switch.
For now I got at least common.tests to compile and run again with nc31. The following link helped me:
https://stackoverflow.com/questions/42861930/unit-tests-not-discovered-in-visual-studio-2017
Great! Oh and I added some github actions to build and test on the server when pushing. Last step will be automated generation on master (so that users will be able to grab nightlies or alike if they want to). As of now it's just a test, not working but I'll fix this soon.
Hehe can happen 😄 I'm off for today now - have a nice evening.
Oops, mouse was hovering on the close now as well 🤕 😄
Hi @harrwiss, thanks! I'm sorry but... Why did you rename the project? Convention still applies here 🤔 😊
You're right, I shouldn't have done that - it's because I made a copy to run them side-by-side to see differences. Now that I removed the old one, I can rename it back though - will do that asap.
Thanks! I'll work a bit on the last optimization I saw for the security log (using on demand async operations which would allow removing the limit), and then l'll check the merge request. I've 20 minutes this morning, could be short 😁
Hi @harrwiss, I merged your modifications, but usually tests should not include external calls and should not rely on network. In our case, it will block testing using CI/CD pipelines on github, which I'd like to use to automate deployment for nightlies :) I'll let you double check that when you have time ;-) Thanks
(and yeah, XTests looked way more fun, but standards really are ;) ) Edit: meant rarely, not really, obviously.
Hi @wokhan, could imagine that you'd like CI/CD pipelines to do the auto testing but the current tests are probably not good enough or only make sense when run manually - running them also doesn't take long.
I created them mostly in TDD style to help me verify things work as expected during development and before pushing e.g. there is a test which just verifies that the WFN.config is there and parsable.
What we could do is probably, to put the tests suitable for CI (e.g. non-network tests) in separate TestSuites (or similar in xunit) and tell the CI pipeline to execute that only 💡
Cheers.
(let's call them XTestSuite's 🤕 )
Hi @harrwiss,
Well then... you can also create separate tests projects for that kind of "live tests for TDD", even if TDD tests should be reusable for CI/CD (using mocks when needed to avoid mentioned issues). I'm a bit tired right now so I won't be able to think about proper naming and best strategy here, but we really need tests on the CI/CD (yep I know there were none before you created some... :-D ). Anyway I'll disable them for now, so the pipeline will be up and running tomorrow or the day after!
Thanks
Switched to NUnit for testing.
Following test categories have been introduced:
- IntegrationTestCategory (for CI/CD tests)
- ManualTestCategory (for manual exploratorive tests useful during development)
- FixmeCategory (for tests which need to be fixed)
Usage in code:
[Test, IntegrationTestCategory]
public void TestInit()
....
The filter categories are shown in the VS Test Explorer (column Traits).
Using filters for dotnet test: ms docs - Running selective unit tests