I do write down all the cases i can think of. And figure ways to test them. Then check them off as i do them. The dev role here usually includes all aspects. You have to figure out the issue. Come up with possible solutions. Code it. Come up with ur test plan. Figure out what all it effects. Look for other interactions. Test. Fix failures. Retest until you are satisfied. Almost always, one person doing all of the above. Some devs have been known to push out untested code. And it tends to show. But much of your testing is dependent on how you interpret that section of code working. There were parts of combat range i did not understand. So I didnt test my changes completely. And broke some stuff. But overall, i think i found additional improvements over its previous function. There have been so many devs over the years. And when diff ppl work on same sections, you end up with parts of code that noone knows how it works. And more often makes it scary to change, as tracing out impacts are not trivial. Thats why here on takp, devs tend to specialize in certain areas. But combat range and mob movement overlap. I specialize in mob movement. But not on combat range. So their interactions got off. Some ppl tend to troll the devs/staff harder. There are a few users who think its their duty to give staff a bad time. From a personal perspective, it sucks. Sucks being singled out, just to be attacked. Its another form of harassment and bullying. In case you want to know what its like being on the receiving side.
Loraen: You are academically correct, but it usually doesn't apply well against giant piles of legacy code with poor or no documentation, and it does take significant time and effort to spin up and keep spinning. It is a fabulous way to do NEW dev, however, if the entire organization, including the money part, are on board with you taking what seems to them to be unreasonable amounts of time doing 'tests'.
I don't know any of the devs here and appreciate very much all their dedication and generosity with their time that they spend on this project. It's really inspiring what this project has been able to do. That being said, writing tests against a legacy codebase with little/no documentation is pretty easy actually and is the best first step to break up, document, understand, refactor, etc etc.. code that is new to you and you want to change. It starts as simple as when you read through a section, write a few tests to add coverage that verifies what you just went over. Exploratory testing I believe is the general name of this technique. It also helps the people who come after you understand what something does, because they can read the test cases. It does take time, but the benefits significantly outweigh. Making changes and watching a test break that you weren't even considering is worth its weight in gold vs the time it takes to fix an issue in production later. I've always found the organization that doesn't understand the value of having a healthy suite of various flavors of testing hasn't fully felt the pain of the amount of money and time, (if repeated often, staff attrition also) that it takes to fix an issue that reaches production that could have been stopped at the development stage with faster feedback on changes via tests. The cost differences are exponential. Of course, the org is never going to tell you to explicitly DO those things, but its up to the dev to do them as part of the craft to support the health of the org even if they (the money people) don't understand all the reasons to do it.
@Kalyrian Right, but there's no 'organization' here. These guys are doing this in their spare time. And even in the real world, no one is arguing against the benefits, but time is always the issue. And in all cases you need to know exactly what the requirements are, and that is often very obscured. I disagree about the difficulty of doing neat little tests against legacy piles; usually you have to rewrite half of it just to get to the point where it's uncoupled enough to be testable at all in an automated way. And listen, if the money people don't understand it, it's not going to happen unless you're willing to work for free. I am all for it, but I'm just saying that is usually much less practical than devs think should be. I'm going to leave it at that, and we can move the discussion out to stack overflow or something if we want to.
Sorry, I didn't say that. I was merely adding onto the comment I quoted about adding tests to a legacy system vs new and it's associated costs with bugs in prod as opposed to dev. But.. you can't honestly, as a developer, say "Er.. what" to writing tests. We both know its the "right" thing to do in software development, but the fact is, this project doesn't make money nor pay you, so I don't blame you for not doing that far. The product is to be moved forward of course. No disrespect meant personally.
I'm aware it doesn't pay you, thats why the first thing I expressed was my appreciation for you and your time spent on this product that you and the other devs supply for us with no fee. I meant other "costs": developer time spent fixing, users experiencing issues.. those other non-monetary things. I don't always see refactoring as an exercise in code I don't understand, but quite the opposite. Usually the first pre-req of refactoring to make something more simple is to understand what it does so it can then be done in a more effective or clear manner. @Fadetree: for sure. I'm on the same page. I know it's not always that easy and things tend to be too tangled up to make it straightforward to get things under test. Been there, rearchitected that. I just wanted to mention it to join the conversation. Sorry to bother you guys, slow day at the office
Something to consider: with Luclin and PoP coming out, game mechanics will get very convoluted with the introduction of AAs. Might get exponentially more difficult to understand all the dependencies and references in the code. What's the effort required to re-write all the code, document it, and write up all the tests. 6 months of effort? What's an average senior dev annual salary, $100k? Can we get $50k donations happening for Haynar before Luclin? ... anyone?
AAs pretty much been done for awhile. Cavedude did them. Most mechanics are done being coded. Just little tweaks here and there as stuff is fine tuned and improved. Rewrite all code, document, and improve. Probably take you 4 or 5 devs, full time, for 2-3 years. At 100k/year, probably $1-1.5million. Ish.
I guess I vastly underestimated how much code there is in EQ. Forgot about the whole part of eqemu running for 15+ years. That's a lot of spaghetti code from dozens/hundreds of different devs. You'd be pretty much writing EQ from scratch. Luclin 2025 here we come
I do rewrite some of the logic in Lua scripts (or in rare cases copy the actual C code) and run them in loops to simulate the behavior many times for some game mechanics, like charm durations, trade skilllups or loot drops. This isn't doable for what Haynar works on though. I think a lot of professional programmers are used to having documentation to look at, conventions followed, and seasoned software engineers having at least framed the skeleton for the overall design for the project even if the juniors fleshed it out with mediocre code. EQEmu has none of this. It's a huge goddamn mess. What EQEmu DOES have is years of servers running the mess, and that's worth a lot. Refactoring breaks a lot of stuff and is very time consuming if the code has little concern for 'black boxing' so any little change can break god knows how many things. A professional coder I used to play EQ with showed desire to help out once, looked at TAKP's source when it was open, and ran the other way. He asked me where the documentation was. Latest EQEmu did refactor a number of things, so it's getting better-- but we forked years ago and merging large refactor commits isn't an option anymore since the forks have diverged so much. TAKP has modified just about everything to some degree.
Me working on complex event script: Try to use API feature A and it doesn't work. Try to use API feature B and it doesn't work. I get annoyed; vent in dev chat. Try to use API feature C and it doesn't work. I quickly complain in chat again, only to discover that it does work and that a code error on my part was at fault. Forced to admit 'nevermind guys' Try to use API feature D and it doesn't work, but now I can't even rant about it. This was not an isolated incident.
Me playing on TAKP: Everything going smooth, works great. NPC kills me. Blame Torven, Blame EQ, Blame Brad McQuaid. Notice I didn't have my shield equipped, and I was missing lots of buffs. Still blame Torven. Make bug report. I never die unless it's a bug.
Playing on Takp Notice quirky mob Pull up Zam start reading comments/clicking links 3 hours later think - shit where did time go
Documentation and conventions - man, that's the dream. Here at work, not a goddamn thing is documented. Our main "product" has a C codebase going back to 1992. The main engine, comm servers, host scrapers, and all of their dependent libraries were written from the ground up in-house, and inline comments are the only documentation. Naturally, giant swaths of code lack any comments whatsoever. If you want to figure out how something flows or see how things mesh together, you have to setup an elaborate environment on your desktop, hook in a debugger, and start poking around for days (which is a shit-ton of fun). What's not a shit-ton of fun is unraveling uncommented, absurdly-complex macro spaghetti written by an eccentric troll who wanted to safeguard his contract renewals..... Sounds like EQEmu is pretty similar. What you guys have done with TAKP is pretty damned awesome.
What I have been trying to say is that I feel like adding tests actually speeds the development process even though it's nominally extra work. This is a new-ish opinion for me, as I have never been a big tester, but I recently worked with a guy who was really into TDD. And I couldn't deny the results. Granted writing tests and refactoring is not exactly fun and this is a hobby, so I totally understand where you are coming from.
