I’ve been getting familiar with git etc, with the end goal of ‘not quite sure yet’ A bit of this a bit of that.
I had a few questions I wasn’t sure about.
I was looking at the test checks that run for a PR. Are all these checks done remotely as in you don’t need to have this setup on your local machine?
Looking at DEVELOPER_TOOLING.md theirs quite a bit to setup. Do you need all that before getting started?
I tested CodeBlocks to compile the game but had issues with the games UI every time. More testing is required on that front.
I tend to try to jump into things before walking and work my way backwards. As a motivational learning exercise I thought about adjusting how Repair Nanobots CBM works.
I always forget to leave it on (always) and it continues to eat up juice after you’ve been fully healed. I thought of trying to code it similar to the fuel CBMs. I.e deactivates after you are fully healed.
I’m not asking anyone to teach me how to code but was interested if it involved editing this part of the code in ‘bionics.cpp’ alone or required other areas also.
Yes, the tests run remotely as soon as you submit your pull request. However, it is always a good practice to run some tests yourself - be it automated or manually loading up a game and test your changes (even if it passes the automated tests).
Part of coding is to just try it out and fail - a lot of the time. Or somehow succeed and wonder how on earth this mess works… Cough.
But yeah, this seems to be the right place to add your changes.
Specifically on tests: if you compile with RUNTESTS=1, then the tests will be compiled in the tests directory, and you can run them with the following command: ./tests/cata_tests --rng-seed time
You can also pass strings to cata_tests to run a specific test or a set of group tests: ./tests/cata_tests --rng-seed time "npc_talk_bionics" runs the npc_talk_bionics test, and ./tests/cata_tests --rng-seed time "[npc_talk]" runs any test keyed as “npc_talk”.
I have a question about the tests. Which I admit only just discovered about 2hrs ago! Did some reading up on Catch2. I understand the concept but not sure how it fits within a workflow.
Using my example…Do I work on bionics.cpp and use Catch2 to test new code. Or do I create a test for new code in Catch2 first. If it checks out implement it within bionics.cpp.
I’m new to C++. I’ve done coding before but at the level it helps you do your job rather than working on a behemoth of a project with many facets.
Probably an idea to get the environment & tools properly set up first then go from there…
There’s a development flow where you write a test for the current behavior, make changes, then use that test you wrote previously to make sure everything’s working (also make whatever changes are necessary for the test).
If there are existing tests in the area, you can use those, but AFAIK, there aren’t many tests for bionics.
Generally, most people test their changes by making them, then loading up the game and fooling around with what they’ve changed.
We’d always welcome more tests, but it’s not necessary to work with them for adding new features.
Ok great. That’s more reassuring. The one thing I try to avoid is bad practices from the start. I joined the discord so will pop over their if I have questions.
I generally try to write my tests first, because repeatedly running a test during a debug cycle is much faster than reloading the game. As an example, I’m currently working on implementing ramps for ground vehicles, and running into cache issues. Running my minimal test case takes about 10 seconds; loading my prepared save game and driving a vehicle up a ramp takes 20-30 seconds.
The problem is that the things you can test with unit tests are limited[1], so eventually you will need to load the game and do real testing. But start with your unit tests.
[1] The main game loop is not coded well, so doing limited test runs is sadly not possible, and certain things depend on user input and that can’t currently be worked around.