A Twitter clone with a Rithm spin.

Live site

# make a virtual environment
mkvirtualenv warbler
# install python requirements
pip install -r requirements.txt

# set up database
dropdb warbler-db
createdb warbler-db
flask db upgrade

# The database must be freshly created before doing this command
# If you have already added data, make sure to follow the steps above
# to reset the database.
psql warbler-db < data.sql

# start the server!
flask run

Try to understand the code. Look through and see what each route is doing. Take a look at the models. See what data you have in your database after running psql warbler-db < data.sql.

When you're ready, address the following user stories:

1. As a user, I want to see a custom 404 page when I try to go to an invalid URL.
2. As a user, I want to see my name, location, bio, and my header image on my profile page.
3. As a user, I want to be able to edit my name, location, bio, and my header image on my profile edit page.
4. As a user, I want to see the last 100 warbles only from the users that I am following, and myself rather than warbles from all users.
5. As a user, I want to be able to "like" a warble.
6. As a user, I want to be able to see how many warbles I "liked" on my profile page.
7. (Technical) - Add tests. Test features such as login, making sure you cannot edit someone else profile, etc. There is a sample test file below. You can also check out the testing notes in the python curriculum. To run the tests, pip install green then run green from the root of your project.

1. As a user, I should not have to refresh the page when I like a warble.
2. As a user, I should not have to refresh the page when I change my bio or name in my profile.
3. As a user, I should not have to go to a new page to compose a warble (think modals and AJAX here!)
4. (Technical) - Look for opportunities to refactor! In the templates especially, there are opportunities to DRY up the code.
5. (Technical) - The application has an n + 1 query issue. Set app.config['SQLALCHEMY_ECHO'] = True and try to fix the issue.

Fair warning: you won't have time to tackle all of these. Pick one or two that interest you!

1. As a user, I should be able to send a direct message to another user which is only visible to the two of us.
2. As a user, I should be able to respond to a direct message sent to me.
3. As a user, I should be able to block another user, so that they are no longer visible to me and they cannot send me direct messages.
4. As a user, I should be able to see a list of all of the users I've blocked.
5. As a user, I should be able to unblock a user I've previously blocked.
6. As an admin user, I should be able to delete anyone's messages.
7. As an admin user, I should be able to delete users from the platform.
8. As an admin user, I should be able to add or revoke admin privileges for any other user.

There are at LEAST two bugs in the application, but it's not necessarily obvious where it is (there's a hint at the bottom of the readme). This is why testing is so important!

Let's briefly discuss a couple of things related to tests: how you should test, and what you should test. First, let's talk about the how. Your test files should all live inside of a folder called tests, and that folder should live inside of your project directory. Inside of tests, you can organize your files however you see fit. For instance, here's what the file structure might look like with four different test files:

.
├── project
│   ├── tests
│   │   ├── test_user_model.py
│   │   ├── test_user_controller.py
│   │   ├── test_message_model.py
│   │   └── test_message_controller.py

In this case, there are four test files: two for testing the models, and two for testing the routes/controllers.

To run the tests, you can run green from the command line (this is one of the requirements in requirements.txt). green is a test runner that will automatically run all tests inside of the project/tests directory. If you want to only run one file, you can do something like green project/tests/NAME_OF_FILE to run tests for that file only. Note that all of your test files should begin with the word test.

So that's how you should test. But what, exactly, should you be testing? Let's take the above file structure as an example.

For model tests, you can simply verify that models have the attributes you expect, and write tests for any model methods.

For the routing and controller tests, things get a bit more complicated. You should make sure that requests to all the endpoints supported in the views files return valid responses. If certain routes are protected, you should make sure that users who are not authenticated or authorized cannot succesfully make those requests. Conversely, if they are authenticated or authorized, they should be able to.

These tests are a bit trickier to write because they require you to make requests in the test, and look through the response in order to verify that the HTML you get back from the server looks correct.

Here are a few different resources for testing your Flask applications.

• Testing with Flask
• Sample Tests for Departments in a many-to-many
• Testing - Logging In and Out

(If you're still looking for those 🐛🐛, scroll down for soome hints.)

For one bug, the first step in producing it is searching for yourself while you're logged in.

For another bug, what happens when you go to /users/login when you're already logged in?