dw_dev | Entries tagged with testing

I can't login to the dwiki right now to update it, so have a post here instead. When updating your dreamhack's database as part of maintenance, you also need to update your test database by running

DW_TEST=1 $LJHOME/bin/upgrading/update-db.pl -r -p --innodb
DW_TEST=1 $LJHOME/bin/upgrading/update-db.pl -r --cluster=all --innodb
DW_TEST=1 $LJHOME/bin/upgrading/texttool.pl load

before restarting Apache. Failure to do that may cause mysterious fatal errors when running automated tests.

momijizukamori

Hello friends! It's been a while since the last API update, but I finally got some bugs fixed, and am now at the point of needing testers to help me find the rest of them so we can get this thing going! If you are interested in helping, you don't need any real coding experience, but you do have to be okay at reading docs.

Instructions:
1) Go to http://www.momiji.hack.dreamwidth.net/create and create an account

2) Go to http://www.momiji.hack.dreamwidth.net/api/

3) Paste the bolded token into the box in the authenication section

4) Click on paths to expand them and use the fields to try the requests out.

5) Report errors or unexpected behavior here!

Note 1: Tropospherical layout CSS is not loading properly for reasons unrelated to the API code that I haven't sorted out yet. Other themes work, and site functionality is fine, just kind of ugly

Note 2: The API demo stuff doesn't match the rest of the styling, and will probably only work on relatively recent browsers (the last year or so). This isn't the final form, I'm just using a third-party package so I can get all the backend stuff working before spending time on making the page pretty and matching to out site styles

Note 3: I'm going to try to get the content-importer going for people who want to import some test data, but the workers are fussy to run in development

Stuff what needs fixing
- ~~/journals/{username}/entries claims to return information about the new entry when you post to it, but currently just returns success or failure~~
- ~~Editing an entry successfully returns no useful information~~
- ~~Requesting a non-existent entryid on a journal returns confusing error~~
- ~~Posting entries currently missing music and location attributes~~
- Posting entries currently missing mood and preformatted attributes

roadrunnertwice

Hello!! I'm looking for volunteers to help test a whole bunch of major changes.

I've got three piles of stuff in the queue:

More design updates for the quick-reply
Refreshed site-skin entry pages (and reply, and icons)
New icon browser on journal pages

Interested? Please read on!

( Instructions and details below the cut )

Current Music: Disasterpeace — The Resonant Canyon

momijizukamori

The new API I've been working on (more discussion here) is getting to the stage where it needs lots of rounds of testing and feedback, because I am extremely scatterbrained and bad at testing. Benefits of helping:
1) get to play with API things now instead of whenever it's ready to go live on the production site
2) my eternal gratitude?
3) idk if you want some custom CSS or something I'm happy to help

In particular, I'd love feedback from people who make use of different security settings on tags, and access and subscription filters, because I don't use these features and thus am less certain of expected behavior.

Caveats
-I don't have API keys working yet, though they're partially written and mostly just need debugging right now. In the meantime, auth is via regular session cookies.
-posting photos is still in the works, because I have to interface with and/or convert an older API to fit the current API conventions, and trying to understand file uploads gives me a headache.
-There is no support for reading or posting comments (outside of inbox notifs) right now, because there needs to be some larger high-level conversations about privacy expectations and what kind of query load the servers can support before we can work out implementation details.
-Icons and image uploads aren't working because I was testing some icon stuff unrelated to the API and slightly borked my config - I will try to get that sorted in the next day or two.

How to do the thing
-Make an account on my dev machine. The workers for content import should be working, if you want to import content from Dreamwidth to play around with.
-Poke at the API - raw JSON-formatted description is here and a slightly cleaner HTML-formatted one is here.
-Leave me feedback! This can be anything you notice - down to 'you misspelled this word'. It's all gotta get fixed at some point, so don't worry about being too picky.

denise

wohali has been working on issue 664 to add a RTE to the new beta update page, and is ready for more eyeballs to poke at it and try to hit weird/unusual use cases or things that could be improved!

If you have a few, please poke at the new RTE on

wohali's dreamhack. To test it:

* Go to http://www.wohali.hack.dreamwidth.net/ and create an account.
* Go to http://www.wohali.hack.dreamwidth.net/beta to turn on the beta update page and http://www.wohali.hack.dreamwidth.net/update to make a post with it.

The update page should default to RTE on the beta update page. To disable it, go to Settings and check "Completely disable the Rich Text Editor (use plain textarea only)". (Historically speaking, a lot of RTE glitches happened when switching from HTML mode to RTE mode, so it's probably worth testing that a bunch.) Accessibility help is available by pressing Alt+0 (zero) while the editor is focused.

If you run into a problem or want to give feedback, you can comment on this entry. If reporting a problem, please include a link to the entry you made so

wohali can see the markup!

kareila

I updated http://wiki.dreamwidth.net/wiki/index.php/Dev_Testing with information about setting up the new test config files and initializing the test database. If you give it a go and run into trouble, leave a comment here. ♥

swaldman

It should work now :-)
Instructions here.

swaldman

So I've been working on Bug 4504 for some time, on and off. It adds the ability to have DW tweet about your new entries. It's nearly ready, and I wouldn't mind some alpha-testing to see if people can find interesting ways to break it.

If you want to have a go,

Create an account on http://www.swaldman.hack.dreamwidth.net/ (I'll leave it live here until further notice, which will be at least a few days)
On the Other Sites settings page there will be a new link "Add New Twitter Account". Do that.
Then it should work just like crossposting, except that only the subject of the entry is of interest.
Let me know (here is good) if you break it in an interesting way, or indeed if you have other comments. Reports of "All works fine for me" are also very welcome, although of course not as useful as bug reports.

Bear in mind that you are theoretically giving me the ability to read and to post to any twitter account that you associate in this way. I'm not going to do anything with it, but it is remotely possible that bugs in my code might - this has not had any code review yet - so you might want to use a non-important account. Please remember to revoke access from https://twitter.com/settings/applications when you've finished playing with this.

A particular maybe-prone-to-oddity area that could use testing is anything involving unicode and >1-byte characters, as they relate to the length of tweets. Twitter should allow 140 characters, not 140 bytes, and hopefully my code should count things correctly to truncate long text in the right place.

Thanks, and have fun :-)

EDIT: At the moment, while tweeting from my Dreamhack seems to work, signing up for new accounts doesn't. I shall investigate and update here, probably around midday GMT on 31st Jan.

Update 31/01: It wasn't me! New account creation doesn't work on the current develop branch. I'll make another post here when it's actually possible for people to test!

Update:

fu fixed the problem. It should work now :-)

Current Mood: nervous

foxfirefey

So, I've gotten into this weird situation on my hack. No matter what I do, my accounts are always Free accounts. I've tried:

* Buying them paid account time in the shop using points, theoretically successfully
* Running workers in case that's what sets it somehow
* Going into admin/capedit and manually setting flags, such as Premium Paid

All to no effect--the account remains free. Anybody replicating this or know what I am doing wrong?

momijizukamori

So I'm working on Bug 647 AKA the 'kill talkread/talkpost with fire' bug. It is probably 99% done! Yaaaaaaaay, etc. It's at the point now where I need testers. Lots and lots of testers, because talkread gets hit a lot, and there's lots of little unusual cases I know I won't think of. So! First and foremost, I'm going to try and keep it live on my DreamHack, and any site-schemed entry or reply page can access it by adding '?fallback=s2' to the end of the URL.

exor674 said she would try to keep it live on her dev env too, for people to look at.

However, we're both working on other bugs too, so we may have to take our branches off live to work on other things. If you want to put the code on your own (git-enabled) dev environment, here's how:

1) Make sure your environment is up to date - the instructions for that are here. Both dw-free and dw-nonfree should be up to date.
2) Make a new branch off of your dw-free develop branch and switch to it.
3) Pull my remote branch by running this: 'git pull https://github.com/momijizukamori/dw-free.git nuketalkread' It'll ask you for a merge commit message - put in whatever.
3) Make a new branch off the dw-nonfree development branch and switch to it.
4) Pull the second remote branch: 'git pull https://github.com/momijizukamori/dw-nonfree.git nuketalkread'
5) Run '$LJHOME/bin/upgrading/update-db.pl --run --populate' to update the database with the new siteviews style.

Now you can use ?fallback=s2 on your pages too! So you can flip back and forth between the old bml view, and the S2 view, and tell me what's different/broken. I haven't actually tested this on comms at all, as I mostly use my Hack for style updates and thus have very little data in terms of entries/comments/users to test this on. Feel free to leave comments here about changes you find that need fixing! And seriously, beat on this thing - this is a page I don't want to fail on live.

Things I already know about:
-All subject lines in comments and entries are linked (it's a core2 issue, we're debating on fix vs leaving it)
-Screened comment count won't show up (again, core2, I'm working on that)
-Metadata on entries that have them have a slightly different alignment (approved change)
-The reply page for replying to comments shows when the comment you're replying to was posted (approved change)
-there's a little bit of space between the bottom of user icons and the bottom of the comment header (not sure how to fix without making the header fixed height, which causes bigger problems elsewhere)

denise

crschmidt pointed out in his bug walkthrough that the process of running the automated test suite is not very well documented! And I agree; I know I don't run the tests when I'm patching things since I don't really know much about it, and I don't contribute tests along with my code because I actually don't know how to write them or what they should do. I am probably not the only one! (The only thing I know about the test suite is that you shouldn't run it in production because it does weird and wonky things to the database.)

I do know that our test suite coverage is not extensive at all, and we've talked before about moving to a more test-driven devlopment mindset. If anybody wanted to write up some documentation on the Wiki about both how to run the tests (and what you should look for) and how to write new tests (and when you should), that would be awesome and I would love you forever. (Well, I mean, I love you all forever already. But I'd love you more forever.)

I stumbled across this useful article which describes how you can quickly set up a VM to run IE:
Internet Explorer for Mac the Easy Way: Run IE 7, IE8, & IE9 Free in a Virtual Machine

Article just mentions a Mac, but Virtual Box also works on Linux, and so do the bash scripts.

Be warned that that it's not all that magic: it makes it easy to set up a testing environment, but it doesn't eliminate the need to have the entire Windows OS downloaded and running in a virtual machine, so you *do* need hard drive space, a decent internet connection, and decent RAM to support all those. Following these instructions will download the entire Windows OS three times, in ~700MB chunks. Right now they're taking up > 40GB on my hard drive; I didn't have enough space on my laptop, so I had to tweak the command from the article to install them to an external hard drive:

curl -s https://raw.github.com/xdissent/ievms/master/ievms.sh | INSTALL_PATH="/my/external/harddrive" bash

Also, even though the images are officially from Microsoft and for testing, they don't count as genuine, so you get the annoying Windows Genuine popups and warnings. Just ignore them and move on with your day -- and testing!

sophie

I've just put a mass user-creation script on the wiki. It allows you to create any number of users and have them be auto-validated. It will also randomly create watch/trust edges between the created users, and if you specify it, they will all join any given community. This makes it extremely useful when you have a bug that requires a large number of users to test, such as bug 2215: member list page: "jump to account" does not jump to username, which requires more than 100 users in a single community.

(I actually already had this script created some time ago, but hadn't released it publicly. However, when I saw

kjwcode manually creating 100 users in order to test the patch on the aforementioned bug, I added the community-joining ability and offered the script to him, and realised I should probably release it for all to use!)

There are a few things the script doesn't do yet. For example, while it can make all the users join a community, it won't make any of them subscribe to it. If anybody wants more features added, let me know!

And, in the interests of code preservation (in case the wiki ever disappears for some reason - not that it should), I'm reproducing the code as it is now inside a cut. Bear in mind that it's possible that the version on the wiki may be more up-to-date if it's been some time since this post was made, so you should probably check on the wiki first!

( Source code follows! )

foxfirefey

Sometimes there are acts of

fu and the next thing you know you have a JavaScript testing framework integrated into our codebase, so as we make the transition to jQuery we can testify as well.

panna

Hi:) I'm a one working on a calendar functionality for Dreamwidth:)

I'd like to ask what to use to test if my code threw exception. I found that this could be tested by Test::Exeption library's commands, but there is no Test/Exception.pm library in Dreamwidth's CPAN.

I found that Dw do use exceptions, but maybe there is preferred to return a specific code? (I prefer throwing exceptions...:P)

wyntarvox

I'm working on t/console-changejournaltype.t One reason it fails is that the console command "change_journal_type" hasn't been updated to be WTF-friendly. This is fairly straightforward to fix, but there's another problem with it.

The can_execute sub for change_journal_type checks for either of two things: a) the user executing the command has the appropriate priv; OR b) $LJ::IS_DEV_SERVER is true. The test, however, only cares about whether the temp_user has the appropriate priv. When the test tries to have temp_user execute change_journal_type without the appropriate priv, it expects the command to error with an inappropriate priv error. However, because on my Dreamhack I have $LJ::IS_DEV_SERVER set to true, the command in fact succeeds which in turn causes the test to fail.

My question is, is it okay to set $LJ::IS_DEV_SERVER to false to get the tests to pass, or should they pass regardless (so we have to rework the tests, for example, to pass if temp_user has the appropriate priv or if $LJ::IS_DEV_SERVER is true)?

mark

I'd like to propose that this coming Tuesday we spend the day doing things to fix tests.

szabgab has done a lot of work on our tests to make them actually run, but they're noisy (with warnings) and some of them are skipped. We should work on improving that.

Testing should really be part of what we do every time we upload a patch to Bugzilla (and we are talking about adding a 'i-ran-the-tests' flag to patches) and not just something we look at on a particular day -- but we have to start somewhere.

So, those of you who want something to do, I challenge you to find a test that isn't working and make it work. You can comment here if you want to claim some of the tests.

Also acceptable: adding new tests!

But for now, focusing on fixing the ones we have is probably more bang for the buck. Up to you, though.

szabgab

Since I started to play with the DW codebase I have been mostly making changes on the test suit and did some code cleanup. Let me write down my plans for the coming weeks:

( Testing )

( Refactoring or code cleanup )

szabgab

In the past few days I managed to fix some of the unit tests and set the rest to be skipped so once my latest patch of bug 1721 gets applied all tests in t/ will either pass or skip.

In order to make development easier in DW it would be important to keep the test suit intact and even adding more tests.

Currently the way to run the tests is by typing

cd $LJHOME
prove t/

In case you would like to run a single test file you can type

prove t/userpics.t

A better way to run the tests will be to run

prove -w t/

but currently it produces lots of warnings, something we should fix soon.

Every time to make a change you should at a minimum make sure that all the tests still pass after the change. If some of the tests stop working you should check if the test is incorrect or if the change you made to the code introduced a real bug and fix it.

( Details )