C#•14mo ago

✅ I don't understand how to test my project.

I have an existing command line project. Since this is a pretty complex project with multiple complex parts, I want to ensure everything is working correctly. How do I go about adding xUnit to this project?

18 Replies

Jimmacle•14mo ago

you'd create a new project for it like MyProject.Tests, add xUnit there, reference your library, and write the tests in that project i suppose you could do it in the same project but i don't think that's common rider should have a xUnit project template

__dil__OP•14mo ago

Oh ok I'm not used to that. I don't mind adding a separate project, but I'm kind of confused how that works w.r.t. privacy. If I understand this correctly, you can't unit-test private or internal methods for example, is that right?

JakenVeina•14mo ago

correct on a general level.... you test the "surface" of your application and you test its "seams" I.E. Integration Testing, and Unit Testing, respectively for example the popular architecture for Desktop GUI apps these days is MVVM one of the primary reasons for this is because it introduces a nice seam at the "top" of your application MVVM involves writing all your important business and user-facing logic into ViewModel classes and then having View classes consume them, usually via bindings Views being things like actual Windows, Buttons, TextBoxes, etc. so, a ViewModel might look like....

public class UserCreationFormViewModel
    : INotifyPropertyChanged,
        INotifyDataErrorInfo
{
    public string UserName { get; set; }
    public string EMailAddress { get; set; }
    public ICommand SaveCommand { get; set; }
}

public class UserCreationFormViewModel
    : INotifyPropertyChanged,
        INotifyDataErrorInfo
{
    public string UserName { get; set; }
    public string EMailAddress { get; set; }
    public ICommand SaveCommand { get; set; }
}

this is a "seam" because it allows you to separate parts of the application that normally work together I.E. the TextBoxes and Buttons that these properties are usually bound to and that's super useful for testing, because simulating interactions with buttons and textboxes can be a pain in the ass, for testing but interacting with object properties is really simple to continue this example, you might also have a seam BELOW the ViewModel layer, such as with a DataAccess layer

public class UserCreationFormViewModel
    : INotifyPropertyChanged,
        INotifyDataErrorInfo
{
    public UserCreationFormViewModel(IUsersRepository usersRepository)

    public string UserName { get; set; }
    public string EMailAddress { get; set; }
    public ICommand SaveCommand { get; set; }
}

public class UserCreationFormViewModel
    : INotifyPropertyChanged,
        INotifyDataErrorInfo
{
    public UserCreationFormViewModel(IUsersRepository usersRepository)

    public string UserName { get; set; }
    public string EMailAddress { get; set; }
    public ICommand SaveCommand { get; set; }
}

here IUsersRepository is an interface with methods on it that just deal with reading and writing user info with an underlying data store, maybe a database or file and it's an interface because what you can do for testing is define a "fake" or "mock" version of that repository that doesn't ACTUALLY do data storage, but just does enough fake behavior to allow for testing and maybe simulates throwing errors or something, too that would be "Unit Testing" in that you're testing just one "Unit" of the application at a time, that being just the ViewModel "Integration Testing" refers to testing where you let as many "real" components of the application operate together as they normally would, to test how well they integrate together

Jimmacle•14mo ago

also, if nobody has told you yet you can "cheat" the internal restrictions using the InternalsVisibleTo assembly-level attribute basically give another assembly permission to look at the assembly's internals

__dil__OP•14mo ago

Oh ok that sounds fun

Jimmacle•14mo ago

good for testing for the question you had earlier

__dil__OP•14mo ago

thanks 😄

JakenVeina•14mo ago

oh, yeah, that's a common pactice put [InternalsVisibleTo] on your main project to allow the test project to use and test internal stuff

__dil__OP•14mo ago

I get a "Program has more than one entry point" error

Jimmacle•14mo ago

how are you structuring your test project? it should be a library with no entry point, an external test runner will discover/run the tests

JakenVeina•14mo ago

then you have inadvertently added multiple entry points into whichever project is giving you that error your main project should really not be touched for you to add testing your test project will actually have no entry point at all

Jimmacle•14mo ago

https://xunit.net/docs/getting-started/netcore/cmdline there's no rider-specific guide but that might help

__dil__OP•14mo ago

I just did "add project" and added a xunit test project without touching anything so I have a solution with two projects inside, one for the command line app, and other for the tests

Jimmacle•14mo ago

sounds right so far the error should specify which project is causing it, i'm guessing you somehow accidentally added another entry point to your command line app

__dil__OP•14mo ago

The error points to my CLI project's main. I didn't even touch that project, I just added the test project 🤷 let's say I did add another entrypoint (which I don't think I did, at least no knowingly), how would I find out where it is, or what should I do

Jimmacle•14mo ago

i'm not sure exactly how the error displays, but if you didn't actually write out an extra Main method you may have accidentally created a file with top-level statements (https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/program-structure/top-level-statements) which is a compiler trick that lets you skip the Main definition boilerplate and generates it around the contents of that file

__dil__OP•14mo ago

Program.cs(9,24): Error CS0017 : Program has more than one entry point defined. Compile with /main to specify the type that contains the entry point.

that can't be right because the program did compile and run just fine before adding the test project and the test project only has one source file, and it does not contain top-level statements Huh, it started spitting a bunch of errors about files being busy so I restarted Rider, and now it all catfacepalm

everything appears to be fine now, all tests passing. Thanks!

Accord•14mo ago

Was this issue resolved? If so, run /close - otherwise I will mark this as stale and this post will be archived until there is new activity.

Gaming

Programming

✅ I don't understand how to test my project.