Jump to content

Matthew

Programmer
  • Content count

    2
  • Joined

  • Last visited

  • Days Won

    1

Daily XP Streak Bonus

XP

Start posting to receive your Daily Streak Bonus for your Adoptable. Every day you post, the more XP you earn.


Matthew last won the day on October 11

Matthew had the most liked content!

Community Reputation

2 Neutral

About Matthew

  • Rank
    Newbie
  1. Bug Reports

    Automated tests are bits of code that you write that you then run before uploading the codebase to your site. In other words, you write the tests in the style of how you expect the code to be, and the tests confirm whether that is actually true or not. For example, below is a piece of code I wrote to check that my emails are being sent out with the correct details. The language is different but the principle is the same. describe "new_forum_post" do let(:mail) { ForumPostNotification.new_forum_post(forum_post(:first), users(:matthew).email) } it "renders the headers" do expect(mail.subject).to eq("A new forum post was made by example!") expect(mail.to).to eq(["matthew@example.com"]) expect(mail.from).to eq(["contact@example.com"]) end it "renders the body" do expect(mail.body).to include("A new forum post was made!") it "includes the unsubscribe link" do expect(mail.body).to include("https://example.com/notifications/unsubscribe") end end These tests run every time I make a change in the codebase, as well as on upload to GitHub (code storage) and the servers. If any of the tests fail (e.g. perhaps the email no longer includes the unsubscribe link, or maybe the subject has changed), the upload will stop and I need to fix whatever is broken before I can upload again. These save you a lot of time and effort over manual testers. Manual testers are important, but it's not realistic to expect people to go and test out every part of the site to make sure nothing has ever broken. These automated tests will probably cut down on the number of regressions (where a feature stops working) and bugs you encounter. Not sure what language you are using, but there are likely to be things that can do this in PHP for example.
  2. Bug Reports

    1. Do you have a test suite implemented for your code base? I find that automated tests before deploying a new version of the game catch most bugs which will help reduce the number of bug reports you have to deal with. As for what a good rate of fixing bugs is, that depends entirely on your team and playerbase. I'd say fix the bugs that are going to have the most impact on your revenue first. 2. I don't typically shut down a feature as such, if a test fails I simply don't deploy the code until it's fixed, but if it somehow breaks in production I immediately revert the change to get back to a known stable state. 3. If I can reproduce the bug and confirm it's had an impact on the player, they get reimbursed with no further questions. 4. No, I've never temporarily taken and held something to determine whether it's a bug or not. 5. By the impact on revenue. If a bug is going to cause me to lose revenue, I need it fixed ASAP. 6. I add them to an internal issue tracker where they can get updates by email. 7. Depends on the type of bug. If it's a cosmetic issue, it's probably not a high priority and they can wait a few weeks. If it's a systems issue (e.g. causing items to disappear) or a payments issue (e.g. they get charged twice or something), then it's a high priority and I aim to get it fixed within hours. 8. I give them the thing back, make a note, and ask them to avoid using that system until I can deploy a patch. 9. The best bug report system are automated tests run before you deploy new code to your servers. :-) They'll help catch regressions, etc. before your players do.
×

Important Information

By using this site, you agree to our Guidelines, Terms of Use, and Privacy Policy.