Tests Writing Hackday!

Tests Writing Hackday!
0

@members Hey guys, we need a kickstart on test writing for our plugins. I think we need a hackday!

We can live code together (whereby.com open in one window), to make some real progress over 24 hours.

How does that sound?

Thoughts welcome on:

  • the date. I’m proposing Nov 30, but open to suggestions
  • the format
  • the plugins

On the plugins I suggest we focus on:

  • @merefield: TLP
  • @fzngagan: Events
  • @pacharanero: QnA (I’ll give you more background beforehand)
  • @angus: Custom Wizard
  • @Eli: focus on our Travis setup running scheduled tests, both CI with GitHub and a regular schedule (I.e every 24 hours). Also consider how we can integrate this into managed updates.
2 Likes

@angus

Love the idea (and I might want to work on the new platform post forthcoming), but I won’t be able to do the 30th. Will come back with a better date after I’ve moved since I’m unsure what plans my family might have set for me without telling me yet.

4 Likes

I agree it’s an excellent idea. 30th is a Saturday, which means I have various family commitments especially in the morning but I could probably put in 6 hours from about 1300-1900 on an average Saturday.

However, since @Eli can’t make the 30th lets see what the alternative dates look like. In general I’d prefer a weekday for this, because as we get into December I am gigging with the band a bit more and Saturdays will start to get pretty full.

3 Likes

@Eli @pacharanero How about the 28th or 29th next week?

The entirety of next week is a no go for me unfortunately, will have to wait until December.
Sorry for the inflexibility.

@members How about 2019-12-04T13:00:00Z?

3 Likes

@members Ok, I’m proposing 2019-12-04T13:00:00Z. Please RSVP in the event controls on this topic if you can make it!

In the lead up to the day, we can discuss the basics of how to write tests and the CI setup we want. I’ll add some thoughts here later today.

1 Like

I got a head start on this today by writing up rspec and qunit tests for the multilingual plugin I’m building for Wikimedia.

A few notes:

  1. You should require the spec/rails_helper at the top of each spec file

    require 'rails_helper'
    

    This will load all the necessary stuff for rspec testing, including whatever you put in plugin/spec/plugin_helper.rb.

    This means plugin_helper.rb is a good spot to put rspec global config. For example I wrapped all tests in a code block to ensure that non-local language data was properly loaded for each test, see: discourse-multilingual/plugin_helper.rb at master · paviliondev/discourse-multilingual · GitHub

  2. It’s easier to run qunit tests in the browser directly than via the command line, e.g.

    http://localhost:3000/qunit?qunit_skip_core=1&qunit_single_plugin=discourse-multilingual
    
  3. For those who already have a .travis.yml file, e.g. events and tlp, this probably needs to be updated in line with the instructions here: Setting up plugin continuous integration tests on Travis CI - developers - Discourse Meta.

1 Like

@merefield @pacharanero @Eli Hey guys, does the 5th work for you?

3 Likes

I’m available Dec 5th from 2019-12-05T07:00:00Z2019-12-05T09:00:00Z and 2019-12-05T10:30:00Z2019-12-05T17:00:00Z

1 Like

@pacharanero Cool :+1:, I’ll lay out a proposed plan for the question answer plugin below tomorrow morning.

I’m going to be working on tests for the custom wizard plugin starting 2019-12-05T04:00:00Z2019-12-05T09:00:00Z then continuing 2019-12-05T22:00:00Z2019-12-06T01:00:00Z. I will be live at whereby.com/thepavilion for that time working on tests.

My plan for the custom wizard plugin

@fzngagan proposed we prepare for this hackday by writing up a list of tests we want to implement.

In that spirit, I’ve laid out what I’m going to focus on for the custom wizard. I’ve created the initial folder structure and written the test titles for a fair chunk of it.

I’ve committed the initial structure and test skeletons to a new branch “add_tests”.

Rspec

For server-side Rspec I’m focusing on:

  1. Core functionality:

    • Saving a wizard template
    • Building and serving a wizard to the user
  2. Brittle points:

    • Send to API action
    • “After time” setting

Rspec folder structure:

spec
  components
     custom_wizard
         api_spec.rb // to test the send to api functionality
         builder_spec.rb // the big one! testing building of wizards
  requests
     custom_wizard
         admin_controller_spec.rb // testing the saving wizard templates
         application_controller_spec.rb // testing user re-routing
         wizard_controller.spec.rb // testing serving the wizard

As a result of this planning process I’m already seeing some ways we can significantly improve the server-side structure of the custom wizard plugin. This often happens when writing tests (and is part of the point).

I may also do these in the process of writing up the rspec tests:

  1. Add an enabled setting!

  2. Move the edits of existing custom wizard classes from the generic ‘wizard_edits.rb’ lib file to proper plugin methods in the plugin.rb file

  3. Properly file the custom wizard classes in the Discourse folder structure

Acceptance

For the acceptance tests I’m going to focus on the behaviour of the custom wizard admin form builder. I’ll add in the structure for that tomorrow.

3 Likes

A little confused about format of event, member involvement approach and attendance arrangements? Do we dial in when we can?

Second session maybe best for UK people though I’ll try to get up and dial in at my 6am. :open_mouth:

1 Like

I will join in as per my above times

I’ll be joining from 2019-12-05T06:30:00Z

Cool, I’m going to push bach my first session to have more overlap with @pacharanero and @fzngagan. I’m now

2019-12-05T04:00:00Z2019-12-05T09:00:00Z then continuing 2019-12-05T22:00:00Z2019-12-06T01:00:00Z

@merefield you can join in whenever suits; 6am sounds a bit early! Don’t sweat if there’s no overlap, but let me know what times work best for you and I’ll tweak my sessions to suit.

@Eli I’ll also give you some guide on what to look at travis-wise.

I’ll be posting what I’ve learnt along the way here.

2 Likes

@pacharanero For the Question Answer plugin.

Firstly, I think it’ll help to address the structural issues in this plugin. This is basically just moving code around, but it’ll help to make it clearer where everything is and how it works together.

  1. The different classes in the 4 files in /lib need to be filed away in the standard rails app structure, with edits to discourse classes going in the plugin.rb using the server-side plugin api (i.e. the methods in discourse/lib/plugin/instance.rb)

  2. The qa_can_vote topic and post methods should be in a guardian.

Then for the tests themselves, I’ve just created a new branch ‘add_tests’ with all the rspec and qunit tests I think are most important in this plugin.

Go through the files one by one, focusing on each class, component or widget at a time. By understanding how each works in turn, it’ll give you a clearer understanding of the whole.

1 Like

@merefield @fzngagan Let me know if you want help with structuring / planning out your rspec and qunit tests.

1 Like

Ok guys, I’m live at Video Meetings, Video Conferencing, and Screen Sharing - Whereby (formerly appear.in) (which has a snazzy new look!) writing tests for the custom wizard plugin.

Aya I confused dates and thought this was tomorrow >.<

No worries!

@members I’m going to be online writing tests again at (new time) 2019-12-06T04:00:00Z2019-12-06T09:00:00Z

@Eli We can talk about travis and CI in our call tomorrow

2 Likes