elons-toys: Inconsistent object instantiations in tests

[Jarak-Jakar]

The first task in the Elon's Toys exercise is to create a buy() method that instantiates a new RemoteControlCar with full battery and 0 metres driven on it. There's nothing stated about writing any other constructor, however.

The first three tests do indeed test that the buy() method behaves appropriately by creating a new car object with the method, but all subsequent tests just instantiate a new object by calling the default constructor directly, bypassing the buy() method. This causes anyone who hasn't overridden the implicit default constructor to fail most subsequent tests.

An example of a solution to the problem which I believe is valid according to the instructions, but which fails, is my first iteration:

using System;

class RemoteControlCar
{
    private const int MetresPerDrive = 20;

    private int _metresDriven;
    private int _batteryPercentage;

    public static RemoteControlCar Buy() =>
        new()
        {
            _metresDriven = 0,
            _batteryPercentage = 100
        };

    public string DistanceDisplay() => $"Driven {_metresDriven} meters";

    public string BatteryDisplay() => _batteryPercentage > 0 ? $"Battery at {_batteryPercentage}%" : "Battery empty";

    public void Drive()
    {
        if (_batteryPercentage > 0)
        {
            _metresDriven += MetresPerDrive;
            _batteryPercentage--;
        }
    }
}

Basically, the issue here to me is that there's no instruction telling people to do anything to constructors, but rather it is implied that the buy method is the appropriate equivalent. After following the instructions, however, it turns out that this is not sufficient to make the tests pass. I suggest either changing the later tests to call RemoteControlCar.buy() instead of using the constructor, or changing the instructions to state explicitly that people should override the default constructor.

[github-actions[bot]]

Hello. Thanks for opening an issue on Exercism. We are currently in a phase of our journey where we have paused community contributions to allow us to take a breather and redesign our community model. You can learn more in this blog post. As such, all issues and PRs in this repository are being automatically closed.

That doesn't mean we're not interested in your ideas, or that if you're stuck on something we don't want to help. The best place to discuss things is with our community on the Exercism Community Forum. You can use [this link](https://forum.exercism.org/new-topic?title=elons-toys:%20%20Inconsistent%20object%20instantiations%20in%20tests&body=The%20first%20task%20in%20the%20Elon's%20Toys%20exercise%20is%20to%20create%20a%20%60buy()%60%20method%20that%20instantiates%20a%20new%20%60RemoteControlCar%60%20with%20full%20battery%20and%200%20metres%20driven%20on%20it.%20%20There's%20nothing%20stated%20about%20writing%20any%20other%20constructor,%20however.%0D%0A%0D%0AThe%20first%20three%20tests%20do%20indeed%20test%20that%20the%20%60buy()%60%20method%20behaves%20appropriately%20by%20creating%20a%20new%20car%20object%20with%20the%20method,%20but%20all%20subsequent%20tests%20just%20instantiate%20a%20new%20object%20by%20calling%20the%20default%20constructor%20directly,%20bypassing%20the%20%60buy()%60%20method.%20%20This%20causes%20anyone%20who%20hasn't%20overridden%20the%20implicit%20default%20constructor%20to%20fail%20most%20subsequent%20tests.%0D%0A%0D%0AAn%20example%20of%20a%20solution%20to%20the%20problem%20which%20I%20believe%20is%20valid%20according%20to%20the%20instructions,%20but%20which%20fails,%20is%20my%20first%20iteration:%0D%0A%0D%0A%60%60%60c#%0D%0Ausing%20System;%0D%0A%0D%0Aclass%20RemoteControlCar%0D%0A%7B%0D%0A%20%20%20%20private%20const%20int%20MetresPerDrive%20=%2020;%0D%0A%0D%0A%20%20%20%20private%20int%20_metresDriven;%0D%0A%20%20%20%20private%20int%20_batteryPercentage;%0D%0A%0D%0A%20%20%20%20public%20static%20RemoteControlCar%20Buy()%20=%3E%0D%0A%20%20%20%20%20%20%20%20new()%0D%0A%20%20%20%20%20%20%20%20%7B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20_metresDriven%20=%200,%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20_batteryPercentage%20=%20100%0D%0A%20%20%20%20%20%20%20%20%7D;%0D%0A%0D%0A%20%20%20%20public%20string%20DistanceDisplay()%20=%3E%20$%22Driven%20%7B_metresDriven%7D%20meters%22;%0D%0A%0D%0A%20%20%20%20public%20string%20BatteryDisplay()%20=%3E%20_batteryPercentage%20%3E%200%20?%20$%22Battery%20at%20%7B_batteryPercentage%7D%25%22%20:%20%22Battery%20empty%22;%0D%0A%0D%0A%20%20%20%20public%20void%20Drive()%0D%0A%20%20%20%20%7B%0D%0A%20%20%20%20%20%20%20%20if%20(_batteryPercentage%20%3E%200)%0D%0A%20%20%20%20%20%20%20%20%7B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20_metresDriven%20+=%20MetresPerDrive;%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20_batteryPercentage--;%0D%0A%20%20%20%20%20%20%20%20%7D%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A%60%60%60%0D%0A%0D%0ABasically,%20the%20issue%20here%20to%20me%20is%20that%20there's%20no%20instruction%20telling%20people%20to%20do%20anything%20to%20constructors,%20but%20rather%20it%20is%20implied%20that%20the%20%60buy%60%20method%20is%20the%20appropriate%20equivalent.%20%20After%20following%20the%20instructions,%20however,%20it%20turns%20out%20that%20this%20is%20not%20sufficient%20to%20make%20the%20tests%20pass.%20%20I%20suggest%20either%20changing%20the%20later%20tests%20to%20call%20%60RemoteControlCar.buy()%60%20instead%20of%20using%20the%20constructor,%20or%20changing%20the%20instructions%20to%20state%20explicitly%20that%20people%20should%20override%20the%20default%20constructor.&category=csharp) to copy this into a new topic there.

---

Note: If this issue has been pre-approved, please link back to this issue on the forum thread and a maintainer or staff member will reopen it.