mirror of
https://github.com/qfpl/applied-fp-course.git
synced 2024-11-22 19:34:33 +03:00
b8921cd1aa
* Add shell.nix that includes sqlite. previous shell environment didn't include an application that was necessary for developing the application. Whoops. This new shell.nix lets students add their own development tools if they want to try something out. `ghcid` for example. * Overhaul: New techniques, new exercises. Remove hspec-wai dependencies, add waargonaut. The aeson dependency has been replaced with waargonaut, and the exercises have been updated to match. Some exercises have been removed. Add the use of `finally` as a demonstration and reminder that we should be cleaning up things like connections when an app is done. Explain the purpose of the `runDB` function so that implementation makes more sense to students as an exercise. Add exercise to generalise the error type that is used in the `AppM` transformer that they implement. This flows onto a later exercise where they reuse this type to simplify a function that is not part of the core application. This also allows for an easier introduction of `ExceptT` as an exercise later in the course when `AppM` is no longer usable. Add a startup error constructor as making the students add it isn't informative when compared to the rest of the exercise. * Remove all duplicate tests. Rebuild Level03. Level03 has been changed entirely to be centered on writing tests for student code. The tests are then to be updated by the students as they progress through the course. There are no duplicated tests and there is a bit more incentive for students to get in and get their hands dirty with respect to testing their own work. Still not sure what to do with doctests just yet. More documentation is required for that. * Remove Level03 exe and modules. * Feedback driven development * Add tighter bounds for lens. * Add bounds for old-locale and contravariant. * Realign some imports. * Rename 'AppM'' to 'AppM' and 'AppM' to 'App'. * Clean up an utterly misleading and out of date comment regarding configuration package choices. Revert to unremarkable statement about it being JSON. * Remove redundant import of `Level02.Types` from `tests/Test.hs`. * Add waargonaut to extra-deps in stack.yaml. * Bump LTS in stack.yaml to 12.14. * Fix typos. * Improve wording, restructure some comments. * Revert LTS bump, increase contravariant upper bound for GHC 8.6.1 * Try updated stack.yaml * Update travis.yml: Bump patch versions of GHC: * 8.4.3 -> 8.4.4 * 8.6.1 -> 8.6.2 Drop Stack LTS: 6, 9, 10 Add Stack LTS: 11, 12 * Add fixes to help stack nightly builds on travis. Remove some comments in cabal file * Remove LTS-11, add in-memory db notes to level04 * add workshop levels document for expansion * Proofread changes. * Try to use cached GHC downloads for stack on travis * Remove install ghc flag from stack commands * Last try to stop stack downloading its own GHC * Revert stack travis changes. Attempt to pin appar version for 7.10.3. * Drop support for GHC 7.10.3
60 lines
2.4 KiB
Haskell
60 lines
2.4 KiB
Haskell
{-# LANGUAGE OverloadedStrings #-}
|
|
module Main where
|
|
|
|
-- | **REMINDER**
|
|
-- This level is not an isolated module to complete. This level exists as one
|
|
-- starting module: `test/Test.hs`. Which you are to import your most recently
|
|
-- completed `Application` to be tested.
|
|
--
|
|
-- As you progress through the course, you are encouraged to return to this
|
|
-- `test/Test.hs` and update it so you're able to be confident that your
|
|
-- application will behave as you expect. You may also write your tests before
|
|
-- you write your functions, this can be useful when trying to think through a
|
|
-- problem.
|
|
|
|
-- | This is the only location for tests as you progress through the course.
|
|
|
|
-- | This module starts our very sparse. There are only the imports required to
|
|
-- have these initial tests work. Additional tests are for you to build. and may
|
|
-- require you to import other modules as you require.
|
|
--
|
|
-- As you progress through the levels, the initialisation of the 'app' will
|
|
-- become more complicated as more components are introduced. Part of the
|
|
-- exercise is to work out how to integrate your application with this testing
|
|
-- framework.
|
|
|
|
-- | 'tasty' takes care of managing all of our test cases, running them,
|
|
-- checking results and then providing us with a report.
|
|
import Test.Tasty (defaultMain, testGroup)
|
|
|
|
-- | 'tasty-wai' makes it easier to create requests to submit to our
|
|
-- application, and provides some helper functions for checking our assertions.
|
|
import Test.Tasty.Wai (assertBody, assertStatus', get, post,
|
|
testWai)
|
|
|
|
-- | For running unit tests for individual functions, we have included the
|
|
-- 'tasty-hunit' package. More information is available on the Hackage page:
|
|
-- https://hackage.haskell.org/package/tasty-hunit.
|
|
--
|
|
-- import qualified Test.Tasty.HUnit as HU
|
|
--
|
|
|
|
import Network.HTTP.Types as HTTP
|
|
|
|
-- | This import is provided for you so you can check your work from Level02. As
|
|
-- you move forward, come back and import your latest 'Application' so that you
|
|
-- can test your work as you progress.
|
|
import qualified Level02.Core as Core
|
|
|
|
main :: IO ()
|
|
main = defaultMain $ testGroup "Applied FP Course - Tests"
|
|
|
|
[ testWai Core.app "List Topics" $
|
|
get "fudge/view" >>= assertStatus' HTTP.status200
|
|
|
|
, testWai Core.app "Empty Input" $ do
|
|
resp <- post "fudge/add" ""
|
|
assertStatus' HTTP.status400 resp
|
|
assertBody "Empty Comment Text" resp
|
|
]
|