Hello,
Unless I am just totally out of it today, I don't see unit tests for this application. Would it be cool if I went ahead and started writing out some tests for the repo?
Unless you prefer a different layout, I propose creating a folder called Lanayo.VagrantManager.Tests in the root directory of the repository (so that the two are neighbors). The folder structure would be identical between the two, and ideally, there would be a 1.1 correspondence between a file in Lanayo.VagrantManager and a matching test file in the new directory. For example, there would be UtilTests.cs containing tests for Util.cs.
I forsee things getting tricky with the UI components, but even if I focus on the non-UI files I think I have plenty to keep me busy.
My choice of tools would be xUnit.NET and FluentAssertions to write the tests, and Moq if I needed to mock any dependencies.
For generating coverage, I would use VS 2019 to do so, assuming that code coverage is not a Premium or Enterprise feature. If it was, I would fall back to using dotCover by Jetbrains. As an open-source contributor, you would be able to get a free license for dotCover as well, along with any of the other frequent contributors, so there is no risk of anyone being "locked out" of configuration coverage.
Please let me know if this approach sounds agreeable to you; nothing is set in stone and I am open to suggestions. I hope to hear from you soon!
--Scott
Hello,
Unless I am just totally out of it today, I don't see unit tests for this application. Would it be cool if I went ahead and started writing out some tests for the repo?
Unless you prefer a different layout, I propose creating a folder called Lanayo.VagrantManager.Tests in the root directory of the repository (so that the two are neighbors). The folder structure would be identical between the two, and ideally, there would be a 1.1 correspondence between a file in Lanayo.VagrantManager and a matching test file in the new directory. For example, there would be UtilTests.cs containing tests for Util.cs.
I forsee things getting tricky with the UI components, but even if I focus on the non-UI files I think I have plenty to keep me busy.
My choice of tools would be xUnit.NET and FluentAssertions to write the tests, and Moq if I needed to mock any dependencies.
For generating coverage, I would use VS 2019 to do so, assuming that code coverage is not a Premium or Enterprise feature. If it was, I would fall back to using dotCover by Jetbrains. As an open-source contributor, you would be able to get a free license for dotCover as well, along with any of the other frequent contributors, so there is no risk of anyone being "locked out" of configuration coverage.
Please let me know if this approach sounds agreeable to you; nothing is set in stone and I am open to suggestions. I hope to hear from you soon!
--Scott